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Abstract 


RFC 5239 defines centralized conferencing (XCON) as an association of 
participants with a central focus. The state of a conference is 
represented by a conference object. This document defines an XML- 
based conference information data model to be used for conference 
objects. A conference information data model is designed to convey 
information about the conference and about participation in the 
conference. The conference information data model defined in this 
document constitutes an extension of the data format specified in the 
Session Initiation Protocol (SIP) event package for conference State. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of REC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6501. 
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1. Introduction 


There is a core data set of conference information that is utilized 
in any conference, independent of the specific conference media. 
This core data set, called the "conference information data model", 
is defined in this document using an XML-based format. The 
conference information data model defined in this document is 
logically represented by the conference object. 


Conference objects are a fundamental concept in centralized 
conferencing, as described in the centralized conferencing framework 
[RFC5239]. The conference object represents a particular 
instantiation of a conference information data model. Consequently, 
conference objects use the XML format defined in this document. 


The Session Initiation Protocol (SIP) event package for conference 
state, specified in [RFC4575], already defines a data format for 
conferences. However, that model is SIP specific and lacks elements 
related to some of the functionality defined by the centralized 
conferencing framework [RFC5239] (e.g., floor control). The data 
model defined in this document constitutes a superset of the data 
format defined in [RFC4575]. The result is a data format that 
supports more call signaling protocols (CSPs) besides SIP and that 
covers all the functionality defined in the centralized conferencing 
framework [RFC5239]. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [REC2119]. 


This document uses the terminology defined in the centralized 
conferencing framework [RFC5239], the SIPPING conferencing framework 
[RFC4353], and the BFCP (Binary Floor Control Protocol) specification 
[RFC4582]. Readers of this document should be familiar with the 
terminology used in those documents. 


3. Overview 


The data model specified in this document is the result of extending 
the data format defined in [RFC4575] with new elements. Examples of 
such extensions include scheduling elements, media control elements, 
floor control elements, non-SIP URIs, and the addition of 
localization extensions to text elements. This data model can be 
used by conference servers providing different types of basic 
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conferences. It is expected that this data model can be further 
extended with new elements in the future in order to implement 
additional advanced features. 


3.1. Data Model Format 
A conference object document is an XML [W3C.REC-xm1-20081126] 


document. Conference object documents MUST be based on XML 1.0 and 
MUST be encoded using UTF-8. 


The normative description of the syntax of the conference object 
document, for use by implementers of parsers and generators, is found 
in the RELAX NG schema provided in Section 5. Compliant messages 
MUST meet the requirements of that schema. 


3.2. Data Model Namespace 
This specification defines a new namespace specification for 


identifying the elements defined in the data model. This namespace 
is as follows: 


urn:ietf:params:xml:ns:xcon-conference-info 


3.3. The Conference Object Identifier 


The conference object identifier (XCON-URI) can be viewed as a key to 
accessing a specific conference object. It can be used, for 
instance, by the conference control protocol to access, manipulate 
and delete a conference object. A conference object identifier is 
provided to the conferencing client by the conference notification 
service or through out-of-band mechanisms (e.g., email). 


A conferencing system may maintain a relationship between the 
conference object identifiers and the identifiers associated with 
each of the complementary centralized conferencing protocols (e.g., 
call signaling protocol, BFCP, etc.). To facilitate the maintenance 
of these relationships, the conference object identifier acts as a 
top-level identifier within the conferencing system for the purpose 
of identifying the interfaces for these other protocols. This 
implicit binding provides a structured mapping of the various 
protocols with the associated conference object identifier. Figure 1 
illustrates the relationship between the identifiers used for the 
protocols and the general conference object identifier (XCON-URI). 
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FSA SAS SS + 
| Conference 
Object 
Identifier 
+2 + 
| xcon:Ji092i@example.com | 
+------ + + 
| 
+ + + 
+ +----------- + + Ho + 
| CSP Conference IDs | |BFCP "Conference ID’ | 
+ + + + 
h323:i092@example.com | 1092 | 
tel:+44 (0) 2920930033 ERP A +--------- + 
| sip:i092@example.com | | 
+2 + +------- + + 
| BFCP "Floor ID’ | 
+ + 
543 
236 
+ + 


Figure 1: Conference Object Mapping 


In Figure 1, the conference object identifier acts as the top-level 
key in the identification process. The call signaling protocols have 
an associated conference user identifier, often represented in the 
form of a URI. The BFCP, as defined in [RFC4582], defines the 
"conference ID’ identifier which represents a conference instance 
within floor control. When created within the conferencing system, 
the "conference ID’ has a 1:1 mapping to the unique conference object 
identifier (XCON-URI). Operations associated with the conference 
control protocols are directly associated with the conference object; 
thus, the primary identifier associated with these protocols is the 


conference object identifier (XCON-URI). The mappings between 
additional protocols/interfaces is not strictly 1:1 and does allow 
for multiple occurrences. For example, multiple call signaling 


protocols will each have a representation that is implicitly linked 
to the top-level conference object identifier, e.g., H323 and SIP 
URIs that represent a conference instance. It should be noted that a 
conferencing system is free to structure such relationships as 
required, and this information is just included as a guideline that 
can be used. 
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Further elements can be added to the tree representation in Figure 1 
to enable a complete representation of a conference instance within a 
conferencing system. 

3.3.1. Conference Object URI Definition 
The syntax is defined by the following ABNF [RFC5234] rules. 


XCON-URI = "xcon" ":" [conf-object-id "@"] host 


conf-object-id = 1*( unreserved / "+" / "=" / wm") 


Note: host and unreserved are defined in RFC 3986 [RFC3986]. 


An XCON-URI is not designed to be resolved, and an application MUST 
NOT attempt to perform a standard DNS lookup on the host portion of 
such a URI in an attempt to discover an IP address or port at which 
to connect. 


3.3.2. Normalization and Conference Object URI Comparison 


In order to facilitate the comparison of the XCON-URI identifiers, 
all the components of the identifiers MUST be converted to lowercase. 
After normalizing the URI strings, the URI comparison MUST be applied 
on a character-by-character basis as prescribed by [RFC3986], Section 
672,1 


The host construction, as defined in RFC 3986, can take the form of 

an IP address, which is not conventionally compared on a character- 

by-character basis. The host part of an XCON-URI serves only as an 

identifier; that is, it is never used as an address. The character- 
by-character comparison still applies. 


3.4. Data Model Structure 


The information in this data model is structured in the following 
manner. All the information related to a conference is contained in 
a <conference-info> element. The <conference-info> element contains 
the following child elements: 


o The <conference-description> element describes the conference as a 
whole. It has, for instance, information about the URI of the 
conference, maximum users allowed in the conference, media 
available in the conference, or the time the conference will 
start. 


o The <host-info> element contains information about the entity 
hosting the conference (e.g., its URI). 
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o The <conference-state> element informs the subscribers about the 
changes in the overall conference information. 


o The <floor-information> element contains information about the 
status of the different floors in the conference. 


o The <users> element describes the membership information as a 
whole. The <users> element contains a set of <user> child 
elements, each describing a single participant in the conference. 


o If a participant in the main conference joins a sidebar, a new 
element is created in the conference referenced from the 
<sidebars-by-ref> element or under one of the <sidebars-by-val> 
elements. 


Note that some of the elements described above such as <conference- 
info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by- 
val> are not defined in the data model in this specification but are 
defined in the data format of [RFC4575]. We describe them here 
because they are part of the basic structure of the data model. 


4. Data Model Definition 


The following non-normative diagram shows the structure of conference 
object documents. The symbol "!" preceding an element indicates that 
the element is REQUIRED in the data model. The symbol "*" following 
an element indicates that the element is introduced and defined in 
this document. That is, elements without a "*" have already been 
defined in [RFC4575]. 


!«conference-info» 
| 
|--<conference-description> 
| --«language»* 
--<display-text> 
| |--<subject> 
| |--<free-text> 
| | -- «keywords» 
| |--<allow-sidebars>* 
| Eu 
| 
| 
| 
| 


--<sidebar-parent>* 

|--<conference-time>* 

|--<entry>* 

| |--<base>* 

| |--<mixing-start-offset>* 

| a 
--«can-join-after-offset»* 

| | --«must-join-before-offset»* 
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| |--<request-user>* 
| |--<notify-end-of-conference>* 
| |--<allowed-extend-mixing-end-offset>* 


--<conf-uris> 
|--<entry> 
|--<uri> 
| |--<display-text> 
| dE 
--«conference-password»* 


--«service-uris» 
|--<entry> 
|--<uri> 
| |--<display-text> 
| |--<purpose> 


--<maximum-user-count> 


--<available-media> 
|--<entry> 

pro ng 
--«type» 
|--<status> 
|--<mixing-mode>* 
|--<codecs>* 

| |--<codec>* 

| | |--<subtype>* 

--<codec>* 

| | |--<subtype>* 

|--<controls>* 

| | --<mute>* 

| | --<gain>* 


| --<display-text> 

| --«type» 

|--«status» 

Se 
--<codecs>* 

| |--<codec>* 

| | |--<subtype>* 

| | --«codec»* 

| |--<subtype>* 

| 


--<controls>* 
|--<pause-video>* 


| 
| 
| 
| 
| 
| 
ak 
| 
| 
| 
| 
| 
| 


Novo, et al. Standards Track [Page 9] 


RFC 6501 Data Model Schema March 2012 


| | | |--<video-layout>* 
| | | 
| cit 


--<host-info> 
|--<display-text> 
| --<web-page> 
|--<uris> 
--<entry> 
|--<uri> 
| | |--<display-text> 


--«conference-state» 
|--<allow-conference-event-subscription>* 
|--<user-count> 

--<active> 


--<floor-information>* 
|--<conference-ID>* 
|--<allow-floor-events>* 
--«floor-request-handling»* 
[e cu 
|--<floor>* 
| |--!<media-label>* 
| |--«algorithm»* 
| |--<max-floor-users>* 

| |--<moderator-id>* 


--<users> 
|--<join-handling>* 
mg 
--<allowed-users-list>* 
dai 
|--<persistent-list>* 
| |--<user>* 
| | -- <email>* 


--«user» 
| --«display-text» 
--<associated-aors> 
ia 
| --<roles> 


| 
| 
| 
|--<deny-users-list>* 
| 
| 
| 
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--<languages> 
--<cascaded-focus> 
--<allow-refer-users-dynamically>* 
--<allow-invite-users-dynamically>* 
--<allow-remove-users-dynamically>* 
--<endpoint> 
--<display-text> 
Bun 
|--«status» 
|--<joining-method> 
|--<joining-info> 
|--<disconnection-method> 
|--<disconnection-info> 


--«media» 

| --«type» 

|--«display-text» 

|--<label> 

|--«src-id» 

|--«status» 

--«to-mixer»* 
|--<floor>* 
|--<controls>* 

| --<mute>* 

| |--<gain>* 


| 
| 
| 
| | SO 
--<from-mixer>* 
| |--<floor>* 
| |--<controls>* 
| | |--<pause-video>* 
| | 
--«call-info» 
|--<sip> 
| |--<display-text> 
| |--<call-id> 
| |--«from-tag» 
| |--<to-tag> 


--«sidebars-by-ref» 
|--<entry> 
| -- <user> 
| |-- <display-text> 
|--<entry> 
= <user> 
-- <display-text> 
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--«sidebars-by-val» 
| --«entry» 


| --<entry> 


The following sections describe these elements in detail. The full 
RELAX NG schema is provided in Section 5. 


4.1. <conference-info> 


A conference object document begins with the root element 
<conference-info>, which is defined in [RFC4575]. The 'state' and 
'version' attributes of the «conference-info» element are defined in 
[RFC4575] and are not used in the context of the XCON Conference 
Information Model since they apply only to notification mechanisms. 


In addition, [RFC4575] defines an 'entity' attribute that contains 
the SIP URI identifier. This specification extends the meaning of 
the 'entity' attribute to the conference object identifier (XCON-URI) 
explained in Section 3.3. 


This specification adds to the <conference-info> element the child 
elements of the «floor-information» element. 


4.2.  «conference-description» 


The <conference-description> element, which is defined in [RFC4575], 
describes the conference as a whole. It SHOULD have an attribute 
'lang' to specify the language used in the contents of this element. 
It is comprised of «language», <display-text>, «subject», <free- 
text», «keywords», <allow-sidebars>, <cloning-parent>, «sidebar- 
parent», «conference-time», «conf-uris», «service-uris», «maximum- 
user-count», and <available-media>. The <display-text>, «subject», 
<free-text>, «keywords», <service-uris>, and <maximum-user-count> 
elements are described in Section 5.3 of [RFC4575]. 


The following sections describe these elements in more detail. Other 


child elements MAY be defined in the future to extend the 
<conference-description> element. 
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4.2.1. <language> 


The <language> element indicates the predominant language that is 
expected to be employed within a conference. This element contains 
only one language. The possible values of this element are the 
values of the 'Subtag' column of the "Language Subtag Registry" at 
[IANA-Lan] originally defined in [RFC5646]. This element does not 
enforce the language of the conference: it only informs the 
participants about the desirable language that they should use in the 
conference. Participants are free to switch to other languages if 
they like. 


4.2.2. <allow-sidebars> 


The <allow-sidebars> element represents a boolean value. If set to 
true or "1", the conference is allowed to create sidebar conferences. 
If absent, or set to "false" or "0", the conference cannot create 
Sidebar conferences. 


4.2.3. <cloning-parent> 


When the <cloning-parent> is present, it indicates that the 
conference object is a child of a parent conference. The «cloning- 
parent» element contains the conference object identifier (XCON-URI) 
(different from the main XCON-URI) of the parent. 


4.2.4. <sidebar-parent> 


When the <sidebar-parent> is present, it indicates that the 
conference object represents a sidebar of another conference. The 
<sidebar-parent> element contains the conference object identifier 
(XCON-URI) (different from the main XCON-URI) of the parent. 


4.2.5. <conference-time> 


The <conference-time> element contains the information related to 
time, policy, and duration of a conference. The <conference-time> 
element contains one or more «entry» elements, each defining the time 
and policy information specifying a single conference occurrence. 

The <conference-time> element differs from the iCalendar objects 
[RFC5545] in that it has the ability to define different policies 
(<can-join-after-offset>, «must-join-before-offset») for the same 
conference at different times. 
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Every <entry> element contains the following child elements: 


o 


Novo, 


«base»: The «base» child element specifies the iCalendar object of 
the conference. The iCalendar object components are defined in 
[RFC5545]. 


«mixing-start-offset»: The <mixing-start-offset> child element 
specifies when the conference media mixing starts before the 
conference starts. The <mixing-start-offset> element specifies an 
absolute value rather than an offset value. If the <mixing-start- 
offset> element is not present, it indicates that the conference 
media mixing starts immediately. The <mixing-start-offset> MUST 


include the 'required-participant' attribute. This attribute 
contains one of the following values: "none", "administrator", 
"moderator", "user", "observer", and "participant". The roles’ 


semantic definitions are out of the scope of this document and are 
subject to future policy documents. More values can be specified 
in the future. The 'required-participant' attribute allows a 
privileged user to define when media mixing starts based on the 
latter of the mixing start time and the time the first participant 
arrives. If the value is set to "none", mixing starts according 
to the mixing start time. 


«mixing-end-offset»: The «mixing-end-offset» child element 
specifies the time conference media mixing stops after the 
conference stops. If the «mixing-end-offset» element is not 
present, it indicates that the conference occurrence is not 
bounded. The «mixing-end-offset» element MUST include the 
'required-participant' attribute. This attribute contains one of 
the following values: "none", "administrator", "moderator", 
"user", "observer", and "participant". More values can be 
Specified in the future. The 'required-participant' attribute 
allows a privileged user to define when media mixing ends based on 
the earlier of the «mixing-end-offset» and the time the last 
participant leaves. If the value is set to "none", mixing stops 
according to the «mixing-end-offset». If the conference policy 
was modified so that the last privileged user is now a normal 
conference participant, and the conference requires a privileged 
user to continue, that conference MUST terminate. 


<can-join-after-offset>: An administrator can indicate the time 
when users can join a conference by populating the «can-join- 
after-offset> element. 


«must-join-before-offset»: An administrator can define the time 


after which new users are not allowed to join the conference 
anymore. 
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o <request-user>: This element defines the time when users or 
resources on the <allowed-users-list> are requested to join the 
conference by using the <request-users> element. 


o <notify-end-of-conference>: The «notify-end-of-conference» element 
defines in seconds when the system MUST send a notification that 
the end of the conference is approaching. If the <notify-end-of- 
conference> element is not present, this indicates that the system 
does not notify the users when the end of the conference is 
approaching. 


o <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing- 
end-offset> element indicates if the conference is allowed to be 


extended. It has a boolean value. 
.2.6. <conf-uris> 
The <conf-uris> contains a set of <entry> child elements -- each 
containing a new element: <conference-password>. This element 


contains the password(s) of the conference, for instance, Public 
Switched Telephone Network (PSTN) conference will store the “PIN 
code’ in this element. All the other <conf-uris> child elements are 
described in Section 5.3.1 of [RFC4575]. 


The RELAX NG schema in Section 5 allows <conference-password> to 
appear anywhere uris-type is expanded. This document only provides 
meaning for <conference-password> appearing as a descendant of the 
<conf-uris> element. Future standardization may give meaning to 
<conference-password> appearing in other elements of type "uris- 
type". In the absence of such standardization, <conference-password> 
MUST NOT appear in elements of type "uris-type" other than <conf- 
uris>. 


.2.7. <available-media> 


The <available-media> element consists of a sequence of <entry> child 
elements. Each <entry> element MAY contain the following child 
elements: 


o The <display-text>, <type>, and <status> elements are described in 
Section 5.3.4 of [RFC4575]. 


o The child element <mixing-mode> describes a default scheduling 
policy by which the mixer will build the outgoing stream from the 
incoming streams. Note that this policy is different than the 
policy describing the floors for each media. The <mixing-mode> 
child element MUST contain one and only one of the "moderator- 
controlled", "FCFS", and "automatic" values, indicating the 
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default algorithm to use with every media stream. The "moderator- 
controlled" value indicates that the moderator of the conference 
controls the media stream policy. The "FCFS" value indicates a 
'first-come-first-served' policy. The "automatic" value means the 
mixer must choose the best scheduling policy for the conference. 


The <codecs> element specifies the allowed codecs in the 
conference. It has an attribute 'decision' that specifies if the 
focus decides the common codec automatically or needs the approval 
of the moderator of the conference ("automatic", "moderator- 
controlled"). The <codecs> element contains <codec> elements. A 
<codec> element can have the attribute 'name' and 'policy'. The 
‘name’ attribute is a codec identifier assigned by the 
conferencing server. The ‘policy’ attribute contains the policy 
for that codec (allowed or disallowed). The <codec> element has 
the child element <subtype>, which stores the codec's name. The 
possible values of this element are the values of the 'subtype' 
column of the "RTP Payload Format media types" registry at [IANA] 
originally defined in [RFC4855]. It is expected that future 
conferencing specifications will define corresponding schema 
extensions, as appropriate. 


The <controls> element contains the basic audio and video global 
control elements for a conference. These controls are sufficient 
for the majority of basic conferences. If the conference server 
wants to support more-advanced controls, then it is RECOMMENDED 
that an extension to the data model be used. In the <controls> 
element, the schema is extensible; hence, new control types Can be 
added in the future. So, moderator controls that affect all media 
output would go under the <available-media> element. The 
following child elements are defined for <controls>: 


* The <mute> element is used in conjunction with an audio stream 
to cease transmission of any audio from the associated stream. 
That means that for the entire duration where mute is 
applicable, all current and future participants of the 
conference are muted and will not send any audio. It has a 
boolean value. If this control is not specified, access to the 
control is not available to the client. 


* The <pause-video> element is used in conjunction with a video 
stream to cease transmission of associated media. It has a 
boolean value. If this control is not specified, the access to 
the control is not available to the client. 
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The <gain> element is used in conjunction with a media output 
stream to indicate the amount of amplification of an audio 
stream. The value is an integer number that ranges from -127 
to 127. If this control is not specified, access to the 
control is not available to the client. 


The <video-layout> element is used in conjunction with a video 
stream to specify how the video streams (of participants) are 
viewed by each participant. Only one layout type can be 
specified for each output stream. If there are fewer 
participants than panels in the specified layout, then blanking 
(black screen) MAY be mixed into the stream on the behalf of 
the missing input streams. If unspecified, the <video-layout> 
default type SHOULD be "single-view". The <video-layout> types 
are as follows, although any number of custom layouts may be 
specified in future extensions: 


+ single-view: Only one stream is presented by the focus to 
all participants in one panel. 


+ dual-view: This dual-view option will present the video 
side-by-side in two panels and not alter the aspect ratio of 


the streams. This will require the focus to introduce 
blanking on parts of the overall image as viewed by the 
participants. 


+ dual-view-crop: This side-by-side layout option instructs 
the focus to alter the aspect ratio of the streams (alter- 
aspect-ratio=true) so that blanking is not necessary. The 
focus handles the cropping of the streams. 


+ dual-view-2x1: This layout option instructs the focus to 
place one stream above the other, in essence, with two rows 
and one column. In this option, the aspect ratio is not 
altered and blanking is introduced. 


+ dual-view-2xl-crop: This layout option also instructs the 
focus to place one stream above the other, in essence, with 
two rows and one column. In this option, the aspect ratio 
is altered and the video streams are cropped. 


+ quad-view: Four equal-sized panels in a 2x2 layout are 
presented by the focus to all participants. Typically, the 
aspect ratio of the streams are maintained (alter-aspect- 
ratio= FALSE). 
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+ multiple-3x3: Nine equal-sized panels in a 3x3 layout are 
presented by the focus to all participants. Typically, the 
aspect ratio of the streams are preserved. 


+ multiple-4x4: 16 equal-sized panels in a 4x4 layout are 
presented by the focus to all participants. Typically, the 
aspect ratio of the streams are preserved. 


+ multiple-5x1: This option refers to a 5x1 layout where one 
panel will occupy 4/9 of the mixed video stream while the 
others will each occupy 1/9 of the stream. Typically, the 
aspect ratio of the streams is preserved. 


+ automatic: This option allows the focus to add panels as 
streams are added. 


4.3. <host-info> 


The <host-info> element and its child elements are described in 
[RFC4575], Section 5.4. 


4.4. <conference-state> 


The <conference-state> is introduced in [RFC4575]. The <conference- 
state> element contains the <allow-conference-event-subscription>, 
<user-count>, «active», and «locked» child elements. The «user- 
count>, <active>, and <locked> child elements are defined in 
[RFC4575], Section 5.5. 


4.4.1. <allow-conference-event-subscription> 


The <allow-conference-event-subscription> element represents a 
boolean action. If set to true, the focus is instructed to allow the 
subscription to conference state events, such as 'SIP event package 
for conference state’ [RFC4575]. If set to FALSE, the subscription 
to conference state events MUST be rejected. If this element is 
undefined, it has a default value of true, causing the subscription 
to conference state events to be accepted. 


4.5. <floor-information> 
The <floor-information> element contains the <conference-ID>, <allow- 
floor-events>, <floor-request-handling>, and <conference-floor- 


policy> child elements. The absence of this element from an XML 
document indicates that the conference does not have a floor. 
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4.5.1. <conference-ID> 


The <conference-ID> represents a conference instance within floor 
control. When BFCP serves as the floor control protocol, the 
<conference-ID> is a 32-bit BFCP conference identifier defined in 
[RFC4582], Section 5.1. Note that when created within the 
conferencing system, there is a 1:1 mapping between this 
<conference-ID> and the unique conference object identifier (XCON- 
URI). 


4.5.2. <allow-floor-events> 


The <allow-floor-events> element represents a boolean action. If set 
to true, the focus is instructed to accept the subscription to floor 
control events. If set to FALSE, the focus is instructed to reject 
the subscription. If this element is undefined, it has a default 
value of FALSE, causing the subscription to floor control events to 
be rejected. 


A conference participant can subscribe himself to a floor control 
event in two different ways: one method is using an offer/answer 
exchange mechanism ([RFC3264]) using SIP INVITE and BFCP parameters 
in the SDP [RFC4583], the other method is a general authorization 
mechanism described in Section 9 of [RFC4582] and in [RFC5018]. 
Future documentation may define additional connection mechanisms. 


4.5.3. <floor-request-handling> 


The <floor-request-handling> element defines the actions used by the 
conference focus to control floor requests. This element defines the 
action that the focus is to take when processing a particular request 
to a floor within a conference. This element defines values of the 
following: 


o "block": This action instructs the focus to deny the floor 
request. This action is the default action taken in the absence 
of any other actions. 


o "confirm": This action instructs the focus to allow the request. 
The focus then uses the defined floor algorithm to further allow 
or deny the floor. The algorithms used are outside the scope of 
this document. 


Note that this section discusses floor control information; 
therefore, the value "block" in a <floor-request-handling> element is 
not related with the "block" value in the <join-handling> element 
(see Section 4.6.1). 
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4.5.4.  «conference-floor-policy» 


The «conference-floor-policy» element has one or more «floor» child 
elements. Every «floor» child elements has an attribute 'id', which 
uniquely identifies a floor within a conference. In the case of BFCP 
[RFC4582], the 'id' attribute corresponds to the floor-id identifier 
defined in [RFC4582], Section 5.2.2. 


o <media-label>: Every floor is identified for one or more mandatory 
<media-label> elements. If the <available-media> information is 
included in the conference document, the value of this element 
MUST be equal to the "label" value of the corresponding media 
Stream «entry» in the «available-media» container. The number of 
those elements indicates how many floors the conference can have. 
A floor can be used for one or more media types; 


o «algorithm»: A floor can be controlled using many algorithms; the 
mandatory «algorithm» element MUST be set to any of the 
"moderator-controlled", "FCFS", or "random" values indicating the 
algorithm. The "moderator-controlled" value indicates that the 
moderator of the conference controls the floor. The "FCFS" value 
indicates a 'first-come-first-served' policy. 


o <max-floor-users>: The <max-floor-users> child element in the 
«floor» element is OPTIONAL and, if present, dictates the maximum 
number of users who can have the floor at one time. 


o <moderator-id>: The OPTIONAL <moderator-id> indicates the "User 
ID" of the moderator(s). It MUST be set if the element 
«algorithm» is set to the "moderator-controlled" value. When the 
floor is created within the conferencing system, the XCON-USERID 
MAY be used as the <moderator-id>. In the case where the BFCP is 
the floor control protocol, the <moderator-id> is defined in 
[RFC4582], Section 3. Note that [RFC4582] refers to the moderator 
role as a "floor chair". 


4.6. «users» 


The «users» element is described in [RFC4575] and contains the «join- 
handling», «user-admission-policy», <allowed-users-list>, and «deny- 
users-list» defined in this document and «user» child elements 
defined in [RFC4575]. When the «users» element is used in the 
context of the XCON Conference Information Model, the 'state' and 
'version' attributes defined in [RFC4575] are not used, since they 
apply only to notification mechanisms. The following sections 
describe these elements in more detail. Other child elements and 
attributes can be used to extend «users» in the future. 
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4.6.1. <join-handling> 


The <join-handling> element defines the actions used by the 
conference focus to control conference participation. This element 
defines the action that the focus is to take when processing a 
particular request to join a conference. This element defines values 
of: 


o "block": This action instructs the focus to deny access to the 
conference. This action is the default action taken in the 
absence of any other actions. 


o "confirm": This action instructs the focus to place the 
participant on a pending list (e.g., by parking the call on a 
music-on-hold server), awaiting moderator input for further 
actions. 


o "allow": This action instructs the focus to accept the conference 
join request and grant access to the conference within the 
instructions specified in the transformations of this rule. 


o "authenticate": This action instructs the focus that the user has 
to provide a combination of username/password. 


o "directed-operator": This action instructs the focus to direct the 
user to an operator. 


4.6.2. <user-admission-policy> 


The <user-admission-policy> is an element that lets an organizer (or 
a participant with appropriate rights) choose a policy for the 
conference that controls how users are authenticated into the 
conference, using a mechanism of the conference's choosing. Since a 
variety of signaling protocols are possible, a variety of 
authentication mechanisms -- determined by every individual 
conference server -- may need to be mapped from the different 
protocols. The specific types of authentication mechanisms are 
beyond the scope of this document. The list of possible values are 
as follows: 


o "closedAuthenticated": A 'closedAuthenticated' policy MUST have 
each conference participant in the allowed users list (listed 
under the <allowed-users-list> element) with each participant 
being sufficiently (up to local policy) authenticated. Conference 
join requests for users not in the allowed users list or 
participants not authenticated should be rejected unless a <join- 
handling» action of 'confirm' is selected; in which case, the user 
is placed on a pending list as indicated earlier. A 
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'closedAuthenticated' policy MUST NOT include a <deny-users-list>. 
If <deny-users-list> appears in the data model, it MUST be 
ignored. 


o "openAuthenticated": An 'openAuthenticated' policy requires each 
conferencing participant to be sufficiently authenticated. 
Typically, this implies that anyone capable of authenticating with 


the conferencing system may join the conference. The 
'openAuthenticated' policy permits the specification of "banned" 
conferencing participants. Such banned users are prevented from 


re-joining the conference until they have been un-banned. An 
'openAuthenticated' policy SHOULD have a deny users list (listed 
under the «deny-users-list» XML element) to support the banning of 
conferencing participants from a conference. An 
'openAuthenticated' policy MUST NOT include an «allowed-users- 
list». If <allowed-users-list> appears in the data model, it MUST 
be ignored. 


o "anonymous": An 'anonymous' policy grants any join requests and is 
the least restrictive policy. An 'anonymous' policy MUST NOT 
include either an <allowed-users-list> or a <deny-users-list>. If 


any of these lists appear in the data model, they MUST be ignored. 


In all other cases, the appearance of an <allowed-users-list> and 
<deny-users-list> MUST be ignored, except as otherwise described in a 
future specification. Future specifications describing the use of 
these lists must provide clear guidance on how to process the lists 
when they occur concurrently, especially when both lists contain the 
same user. For example, such a specification could disallow both 
lists from appearing at the same time similar to «user-admission- 
policy» values defined in this document. 


4.6.3. <allowed-users-list> 


The «allowed-users-list» child element contains a list of user URIs 
(e.g., XCON-USERID, as defined in Section 4.6.5), roles (defined in 
Section 4.6.5.2), or domains (e.g., *@example.com) that the focus 
uses to determine who can join the conference, who can be invited to 
join a conference, or who the focus needs to "refer to" the 


conference. The <allowed-users-list> element includes zero or more 
«target» child elements. This child element includes the mandatory 
‘uri’ attribute and the mandatory 'method' attribute. The same 'uri' 


attribute with different method values can appear in the list more 
than once. 
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The ‘method’ attribute is a list with the following values: 


o "dial-in": The value "dial-in" is used by the focus to determine 
who can join the conference. 


o "dial-out": The value "dial-out" contains a list of resources with 
which the focus will initiate a session. 


o "refer": The value "refer" is used by the focus to determine the 
resources that the focus needs to "refer to" the conference. In 
SIP, this is achieved by the focus sending a REFER request to 
those potential participants. In a different paradigm, this could 
also mean that the focus sends an SMS or an email to the referred 
user. This list can be updated during the conference lifetime so 
it can be used for mid-conference refers as well. 


The "refer" value differs from "dial-out" in that the resources on 
the "refer" value are expected to initiate the session establishment 
toward the focus themselves. It is also envisioned that different 
users will have different access rights to those lists and therefore 
a separation between the two is needed. 


The <allowed-users-list> element has a <persistent-list> child 
element as well. Some chat room systems allow -- and some require -- 
registration of detailed information about a user before they are 
allowed to join a chat room. The <persistent-list> child element 
stores persistent information about users who are not actively part 
of an ongoing chat room session. The <persistent-list> element 
stores the following information: 


o user: The <user> element stores the name, nickname, conference 
user identifier (XCON-USERID), and email address of a user. TE 
has three attributes: ‘name’, ‘nickname’, and 'id' and an «email» 
element. Future extensions to this schema may define new elements 
for the <user> element. 


Future extensions to this schema may define new elements for the 
<target> element. 


4.6.4. <deny-users-list> 


The <deny-users-list> child element contains a list of user URIs 
(e.g., SIP URI, XCON-USERID defined in Section 4.6.5), roles (defined 
in Section 4.6.5.2), or domains (e.g.: *@example.com) that the focus 
uses to determine who has been ‘banned’ from the conference. Such 
banned users are prevented from re-joining the chat room until the 
ban has been lifted. 
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4.6.5. «user» and Its «user» Sub-Elements 


The element «user» is described in [RFC4575] and describes a single 
participant in the conference. The «user» element has an attribute 
'entity'. However, when the «user» element is used in the context of 
the XCON Conference Information Model, the 'state' and 'version” 
attributes defined in [RFC4575] are not used, since they only apply 
to notification mechanisms. 


The attribute 'entity' contains a unique conference user identifier 
(XCON-USERID) within the scope of the conference. The URI format of 
this identifier is as follows (using ABNF [RFC5234]): 


XCON-USERID = "xcon-userid" ":" conf-user-id 
conf-user-id = 1*unreserved 
Note: unreserved is defined in RFC 3986. 


In order to facilitate the comparison of the XCON-USERID identifiers, 
all the components of the identifiers MUST be converted to lowercase. 


After normalizing the URI strings, the URIs comparison MUST be 
applied codepoint-by-codepoint after conversion to a common character 
encoding, as prescribed by [RFC3986], Section 6.2.1. 


Other user identifiers can be associated with this conference user 
identifier and enable the conferencing system to correlate and map 
these multiple authenticated user identities to a single global user 
identifier. Figure 2 illustrates an example using the conference 
user identifier in association with the user identity defined for 
BFCP, SIP, and H323 user identity. It should be noted that a 
conferencing system is free to structure such relationships as 
required, and this information is just included as a guideline. 
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+ + 
| Conference | 
User 
Identifier 
+ + 
| XCON-USERID: John | 
+------- + + 
| 
+ + + 
| | 
+------- + + An e + + 4 + + 
| BFCP User ID | | SIP User URI | | H323 User URI 
+ + 4-22 + 4-22 + 
| 543 | |sip:851221@example.com | |h323:taeduk@example.com| 
+ + 4-22 + 4-22 + 


Figure 2: Conference User Mapping 


The element <user> element contains the <display-text>, <associated- 
aors>, <provide-anonymity>, <roles>, <languages>, <cascaded-focus>, 
<allow-refer-users-dynamically>, <allow-invite-users-dynamically>, 
<allow-remove-users-dynamically>, and <endpoint>. The following 
sections describe these elements in more detail. The <display-text>, 
<associated-aors>, <languages>, and <cascaded-focus> are defined in 
[RFC4575], Section 5.6. 


4.6.5.1. <provide-anonymity> 


The <provide-anonymity> element specifies what level of anonymity the 
server should provide to the user. In this case, the focus provides 
the rest of the participants with an anonymous identity for that 
user, for example, anonymousX, or it does not provide any information 
for that user such that other users cannot see he is a participant in 
the conference. This element only affects the way the user 
information is provided to the other participants. The real user 
information is stored in the data model but SHOULD NOT be provided to 
the other participants of the conference. This can be achieved by 
using the <provide-anonymity> element. This element has three 
values: "private", "semi-private", and "hidden". The "private" value 
specifies that this user is completely anonymous in the conference. 
The "semi-private" value specifies that this user is anonymous to all 
users who have not been granted permission to see him. The "hidden" 
value specifies that other users cannot see this participant in the 
conference. 
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4.6.5.2. <roles> 


A <role> provides the context for the set of conference operations 


that a participant can perform. This element can contain one or more 
of the following values: "administrator", "moderator", "user", 
"participant", "observer", and "none". A role of "none" indicates 


that any role is assigned. The <roles> semantic definition is out of 
the scope of this document and is subject to future policy documents. 
This element can be extended with new roles in future documents. 


4.6.5.3. <allow-refer-users-dynamically> 


The <allow-refer-users-dynamically> element represents a boolean 
value. If set to true, a participant is allowed to instruct the 
focus to refer a user to the conference without modifying the 
<allowed-users-list> (in SIP terms, a participant is allowed to send 
a REFER request [RFC3515] to the focus, which results in the focus 
sending a REFER request to the user the referrer wishes to join the 
conference). If set to FALSE, the REFER request is rejected. If 
this element is undefined, it has a value of FALSE, causing the REFER 
request to be rejected. 


4.6.5.4. <allow-invite-users-dynamically> 


The <allow-invite-users-dynamically> element represents a boolean 
action. If set to true, a participant is allowed to instruct the 
focus to invite a user to the conference without modifying the 
<allowed-users-list> list (in SIP terms, a participant is allowed to 
send a REFER request [RFC3515] to the focus, which results in the 
focus sending an INVITE request to the user the referrer wishes to 
join the conference). If set to FALSE, the REFER request is 
rejected. If this element is undefined, it has a value of FALSE, 
causing the REFER request to be rejected. 


4.6.5.5. <allow-remove-users-dynamically> 


The <allow-remove-users-dynamically> element represents a boolean 
action. If set to true, a participant is allowed to instruct the 
focus to remove a user from the conference without modifying the 
ruleset (in SIP terms, a participant is allowed to send a REFER 
request [RFC3515] to the focus, which results in the focus sending a 
BYE request to the user the referrer wishes to leave the conference). 
If set to FALSE, the REFER request is rejected. If this element is 
undefined, it has a value of FALSE, causing the REFER request to be 
rejected. 
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4.6.5.6. <endpoint> 


The <endpoint> child element is identical to the element with the 
same name in [RFC4575] except that the 'state” attribute is not 
included. When the <endpoint> element is used in the context of the 
XCON Conference Information Model, the 'state' and ‘version’ 
attributes defined in [RFC4575] are not used, since they apply only 
to notification mechanisms. The <endpoint> element can provide the 
desired level of detail about the user's devices and their signaling 
sessions taking part in the conference. 


The <endpoint> element has the following child elements: <display- 
text>, <referred>, <status>, <joining-method>, <joining-info>, 
<disconnection-method>, <disconnection-info>, <media>, and <call- 
info>. All the <endpoint> child elements are defined in [RFC4575] 
with the exception of the <to-mixer> element and the <from-mixer> 
element. 


The <endpoint>/<media> element has two other child elements defined 
in this document: the <to-mixer> and the <from-mixer>: 


o <from-mixer>, <to-mixer>: These are controls that apply to a 
user's media stream being sent from the mixer to the participant's 
endpoint or to the mixer from the participant’s endpoint. The 
<to-mixer> element details properties associated with the incoming 
streams to the mixer (streams sent to the mixer from the 


participant). The <from-mixer> element details properties 
associated with the outgoing streams from the mixer (sent from the 
mixer to the participant). Both of these elements have the 
attribute 'name'. The 'name' attribute has the values "VideoIn", 
"VideoOut", "AudioOut", and "AudioIn". The "VideoOut" and 


"AudioOut" media streams detail properties associated with the 
outgoing video and audio from the mixer. The "VideoIn" and 
"AudioIn" media stream details properties associated with the 
incoming video and audio to the mixer. Both of these elements can 
have the «floor» child element defined: 


* The «floor» element refers to the floor assigned to a certain 
participant in the conference. If a participant, for instance, 
needs to talk in the conference, it first needs to get the 
floor from the chair of the conference. The «floor» element 
has an attribute 'id', which uniquely identifies a floor within 
a conference. The 'id' attribute corresponds to the floor-id 
identifier defined in [RFC4582], Section 5.2.2. The «floor» 
element has a boolean value. A value of FALSE indicates that 
this user does not hold the floor in this moment. If this 
control is not specified, this user SHOULD NOT specify the 
floor option. 
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The <to-mixer> and <from-mixer> elements can have the <controls> 
child element: 


* Controls that apply to a specific user would appear under the 
<controls> element. 


o More values can be defined in the future. 
4.7. <sidebars-by-ref> 


The <sidebars-by-ref> element contains a set of <entry> child 
elements. This element is described in [RFC4575], Section 5.9.1. 
When the <sidebars-by-ref> element is used in the context of the XCON 
conference information model, the 'state' and ‘version’ attributes 
defined in [RFC4575] are not used, since they apply only to 
notification mechanisms. 


4.8. <sidebars-by-val> 


The <sidebars-by-val> element contains a set of <entry> child 
elements each containing information about a single sidebar. This 
element is described in [RFC4575], Section 5.9.2. When the 
<sidebars-by-val> element is used in the context of the XCON 
conference information model, the ‘state’ and “version” attributes 
defined in [RFC4575] are not used, since they apply only to 
notification mechanisms. 


5. RELAX NG Schema 


In accordance with the centralized conferencing framework document 
[RFC5239], the conference object is a logical representation of a 
conference instance. The conference information schema contains core 
information that is utilized in any conference. It also contains the 
variable information part of the conference object. 


The normative schema is backwards compatible with [RFC5239], in other 
words, valid [RFC5239] instance documents are also valid according to 
this RELAX NG schema [RELAX]. In addition to approximately similar 
RELAX NG [RELAX] definitions of [RFC5239], this schema contains 
extension elements in the 
"urn:ietf:params:xml:ns:xcon-conference-info" namespace. 
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default namespace = "urn:ietf:params:xml:ns:conference-info" 
namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info" 


start = element conference-info { conference-type } 
# CONFERENCE TYPE 
conference-type = 

attribute entity { text } 
anyAttribute 
conference-description-type? 
element host-info { host-type }? 
element conference-state { conference-state-type }? 
element users { users-type }? 
element sidebars-by-ref { uris-type }? 
element sidebars-by-val { sidebars-by-val-type }? 
element xcon:floor-information { floor-information-type }? 

& anyElement* 
# CONFERENCE DESCRIPTION TYPE 
conference-description-type = 

element conference-description ( 

attribute xml:lang { xsd:language }? 
& anyAttribute 

element display-text { text }? 
element subject { text }? 
element free-text { text }? 
element keywords { 

list { xsd:string* } 
12 
element conf-uris { uris-type }? 
element service-uris { uris-type }? 
element maximum-user-count { xsd:int }? 
element available-media { conference-media-type }? 
element xcon:language { xsd:language }? 
element xcon:allow-sidebars { xsd:boolean }? 
element xcon:cloning-parent { xsd:anyURI }? 
element xcon:sidebar-parent { xsd:anyURI }? 
element xcon:conference-time { conferencetime-type }? 
anyElement* 


GO B SO SMHS SO | E 


& 
& 
& 
& 


ee QQ m SO SO SO SO SG 


} 

# HOST TYPE 

host-type = 
element display-text { text }? 
& element web-page { xsd:anyURI }? 
& element uris { uris-type }? 
& anyElement* 
& anyAttribute 

# CONFERENCE STATE TYPE 

conference-state-type = 
anyAttribute 
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element user-count { xsd:unsignedInt }? 
element active { xsd:boolean }? 
element locked { xsd:boolean }? 
element xcon:allow-conference-event-subscription { xsd:boolean }? 
anyElement* 
# CONFERENCE MEDIA TYPE 
conference-media-type = 
anyAttribute 
& element entry { conference-medium-type }* 
& anyElement* 
# CONFERENCE MEDIUM TYPE 
conference-medium-type = 
attribute label { text } 
anyAttribute 
element display-text { text }? 
element type { text }? 
element status { media-status-type }? 
element xcon:mixing-mode { mixing-mode-type }? 
element xcon:codecs { codecs-type }? 
element xcon:controls { control-type }? 
anyElement* 
# URIs TYPE 
uris-type = 
anyAttribute 
& element entry { uri-type }* 
& anyElement* 
# URI TYPE 
uri-type = 
element uri { xsd:anyURI } 
& element display-text { text }? 
& element purpose { text }? 
& element modified { execution-type }? 
& element xcon:conference-password { text }* 
& 
& 


QAR QQ 


GO m m SMHS | E 


anyElement* 
anyAttribute 
# USERS TYPE 
users-type = 
anyAttribute 
element user { user-type }* 
element xcon:join-handling { join-handling-type }? 
element xcon:user-admission-policy { user-admission-policy-type }? 
element xcon:allowed-users-list { allowed-users-list-type }? 
element xcon:deny-users-list { deny-user-list-type }? 
anyElement* 
# USER TYPE 
user-type = 
attribute entity { xsd:anyURI } 
& anyAttribute 


SO SO SO mmm 
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display-text { text }? 
associated-aors { uris-type }? 
roles { 


element entry { single-role-type }+ 


}? 
& element 


languages { 


list { xsd:language } 


}? 

element 
element 
element 
element 
element 
element 


$m mm SO EO 


cascaded-focus { xsd:anyURI }? 
endpoint { endpoint-type }* 
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xcon:provide-anonymity { provide-anonymity-type }? 
xcon:allow-refer-users-dynamically { xsd:boolean }? 
xcon:allow-invite-users-dynamically { xsd:boolean }? 
xcon:allow-remove-users-dynamically { xsd:boolean }? 
& anyElement* 
# ENDPOINT TYPE 
endpoint-type = 


attribute entity { text } 
anyAttribute 
element display-text { text }? 


element 
element 
element 
element 
element 
element 
element 
element 
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referred { execution-type }? 

status { endpoint-status-type }? 
joining-method { joining-type }? 
joining-info { execution-type }? 
disconnection-method { disconnection-type 
disconnection-info { execution-type }? 
media { media-type }* 

call-info { call-type }? 


& anyElement* 
# ENDPOINT STATUS TYPE 
endpoint-status-type = 


"pending" 


"dialing-out" 
"dialing-in" 
"alerting" 


"connected" 
"muted-via-focus" 
"disconnecting" 
| "disconnected" 
free-text-extension 
# JOINING TYPE 


joining-type 


| 
| "on-hold" 
| 
| 
| 


}? 


"dialed-in" | "dialed-out" | "focus-owner" | free-text-extension 
# DISCONNECTION TYPE 
disconnection-type = 
"departed" | "booted" | "failed" | "busy" | free-text-extension 
# EXECUTION TYPE 
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execution-type = 
element when { xsd:dateTime }? 
& element reason { text }? 
& element by { xsd:anyURI }? 
& anyAttribute 
# CALL TYPE 
call-type = 
element sip { sip-dialog-id-type } 
& anyElement* 
& anyAttribute 
# SIP DIALOG ID TYPE 
sip-dialog-id-type = 
element display-text { text }? 
& element call-id { text } 


& element from-tag { text } 
& element to-tag { text } 

& anyElement* 

& anyAttribute 


# MEDIA TYPE 
media-type = 
attribute id { xsd:int } 
anyAttribute 
element display-text { text }? 
element type { text }? 
element label { text }? 
element src-id { text }? 
element status { media-status-type }? 
element xcon:to-mixer { mixer-type }? 
element xcon:from-mixer { mixer-type }? 
anyElement* 
# MEDIA STATUS TYPE 
media-status-type = 
"recvonly" 
"sendonly" 
"sendrecv" 
| "inactive" 
free-text-extension 
# SIDEBARS-BY-VAL TYPE 
sidebars-by-val-type = 
anyAttribute 
& element entry { conference-type }* 
& anyElement* 
# CONFERENCE TIME 
conferencetime-type = 
anyAttribute 
& element xcon:entry { 
element xcon:base { text }, 
element xcon:mixing-start-offset { 
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time-type, 


attribute required-participant { single-role-type }, 


anyAttribute 

}?, 

element xcon:mixing-end-offset ( 
time-type, 


attribute required-participant { single-role-type }, 


anyAttribute 
}?, 


element xcon:can-join-after-offset { time-type }?, 
element xcon:must-join-before-offset { time-type }?, 


element xcon:request-user { time-type } 


? 
tg 
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element xcon:notify-end-of-conference { xsd:nonNegativeInteger }?, 
element xcon:allowed-extend-mixing-end-offset { xsd:boolean }?, 


anyElement* 
)* 
4 TIME TYPE 
time-type = xsd:dateTime { pattern = ".+T.+Z. 
# SINGLE ROLE TYPE 
single-role-type = 
xsd:string "none" 
xsd:string "administrator" 
xsd:string "moderator" 
| xsd:string "user" 
| xsd:string "observer" 
| xsd:string "participant" 
| free-text-extension 
# MIXING MODE TYPE 
mixing-mode-type = 
xsd:string "moderator-controlled" 
| xsd:string "FCFS" 
| xsd:string "automatic" 
| free-text-extension 
# CODECS TYPE 
codecs-type = 
attribute decision { decision-type } 
& anyAttribute 
& element xcon:codec { codec-type }* 
& anyElement* 
# CODEC TYPE 
codec-type = 
attribute name { text } 
& attribute policy { policy-type } 
& anyAttribute 
& element xcon:subtype { text }? 
& anyElement* 
# DECISION TYPE 
decision-type = 
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xsd:string "automatic" 
| xsd:string "moderator-controlled" 
| free-text-extension 
# POLICY TYPE 
policy-type = 
xsd:string "allowed" | xsd:string "disallowed" | free-text-extension 
# CONTROL TYPE 
control-type = 
anyAttribute 


& element xcon:mute { xsd:boolean }? 
& element xcon:pause-video { xsd:boolean }? 
& element xcon:gain { gain-type }? 
& element xcon:video-layout { video-layout-type }? 
& anyElement* 
# GAIN TYPE 
gain-type = xsd:int { minInclusive = "-127" maxInclusive = "127" } 


# VIDEO LAYOUT TYPE 
video-layout-type = 
xsd:string "single-view" 
| xsd:string "dual-view" 
| xsd:string "dual-view-crop" 
| xsd:string "dual-view-2x1" 
xsd:string "dual-view-2x1-crop" 
| xsd:string "quad-view" 
| xsd:string "multiple-3x3" 
| xsd:string "multiple-4x4" 
| xsd:string "multiple-5x1" 
| xsd:string "automatic" 
free-text-extension 
# FLOOR INFORMATION TYPE 
floor-information-type = 
anyAttribute 
element xcon:conference-ID { xsd:unsignedLong }? 
element xcon:allow-floor-events { xsd:boolean }? 
element xcon:floor-request-handling { floor-request-type }? 
element xcon:conference-floor-policy { conference-floor-policy }? 
anyElement* 
# FLOOR REQUEST TYPE 
floor-request-type = 
xsd:string "block" | xsd:string "confirm" free-text-extension 
# CONFERENCE FLOOR POLICY 
conference-floor-policy - 
anyAttribute 
& element xcon:floor { 
attribute id { text } 
& anyAttribute 
& element xcon:media-label { xsd:nonNegativeInteger }+ 
& element xcon:algorithm { algorithm-type }? 


nn mmm 
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& element xcon:max-floor-users { xsd:nonNegativeInteger }? 
& element xcon:moderator-id { xsd:nonNegativeInteger }? 
& anyElement* 
}+ 
# ALGORITHM POLICY 
algorithm-type = 
xsd:string "moderator-controlled" 
| xsd:string "FCFS" 
xsd:string "random" 
free-text-extension 
# USERS ADMISSION POLICY 
user-admission-policy-type = 
xsd:string "closedAuthenticated" 
| xsd:string "openAuthenticated" 
| xsd:string "anonymous" 
| free-text-extension 
# JOIN HANDLING TYPE 
join-handling-type = 
xsd:string "block" 
| xsd:string "confirm" 
| xsd:string "allow" 
xsd:string "authenticate" 
xsd:string "directed-operator" 
| free-text-extension 
# DENY USERLIST 
deny-user-list-type = 
anyAttribute 
& element xcon:target { 
attribute uri { xsd:anyURI }, 
anyAttribute 
)* 
& anyElement* 
# ALLOWED USERS LIST TYPE 
allowed-users-list-type - 
anyAttribute 
& element xcon:target { target-type }* 
& element xcon:persistent-list { persistent-list-type }? 
& anyElement* 
# PERSISTENT LIST TYPE 
persistent-list-type - 
element xcon:user ( 
attribute name { text } 
attribute nickname { text } 
attribute id { text } 
anyAttribute 
element xcon:e-mail { text }* 
anyElement* 


nn mmm 


)* 
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& anyElement* 
# TARGET TYPE 
target-type = 
attribute uri { xsd:anyURI }, 
attribute method { method-type ), 
anyAttribute 
# METHOD TYPE 
method-type = 
xsd:string "dial-in" 
| xsd:string "dial-out" 
| xsd:string "refer" 
| free-text-extension 
# ANONYMITY TYPE 
provide-anonymity-type = 


"private" | "semi-private" | "hidden" | free-text-extension 


# MIXER TYPE 
mixer-type = 
attribute name { mixer-name-type } 
& anyAttribute 
& element xcon:controls { control-type }* 
& element xcon: floor { 
attribute id { text }, 
anyAttribute, 
xsd:boolean 
)* 
& anyElement* 
# MIXER NAME TYPE 
mixer-name-type - 


"VideoIn" | "videoOut" | "AudioOut" | "AudioIn" 


# FREE TEXT EXTENSION 
# 


free-text-extension = text 


+ kkkxkxkxkxkxkxkxkxkxkxkxkxkxkxkxkxkxkxkkxkxkxkkxkxkkkxkxkx*k 
# EXTENSIBILITY OF THE SCHEMA 
# KAKKAKAKKKAAKAKKAAKAKKAAKAKAAKKAKAAKAKAAKKAKAAAKAAA 
# EXTENSIBILITY ELEMENTS 
# 
anyElement = 
element * - (conference-description 
| host-info 
conference-state 
users 
| sidebars-by-ref 
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sidebars-by-val 
display-text 
subject 
free-text 
keywords 
conf-uris 
service-uris 
maximum-user-count 
available-media 
web-page 

uris 

uri 

user-count 
active 

locked 

entry 

type 


status 

purpose 
modified 

user 
associated-aors 
roles 

languages 
cascaded-focus 
endpoint 
referred 
joining-method 
joining-info 
disconnection-method 
disconnection-info 
media 

call-info 

when 

reason 

by 

sip 

call-id 
from-tag 
to-tag 

label 
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src-id 


xcon 


xcon 


xcon 


xcon 


xcon 


xcon 


xcon 


xcon 


:conference-password 
xcon: 
:codecs 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
:allowed-users-list 
xcon: 
xcon: 
xcon: 
:provide-anonymity 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
:pause-video 
xcon: 
:video-layout 
xcon: 
:allow-floor-events 
xcon: 
:conference-floor-policy 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 
xcon: 


mixing-mode 


controls 

language 

allow-sidebars 

cloning-parent 

sidebar-parent 
allow-conference-event-subscription 
to-mixer 

provide-anonymity 
allow-refer-users-dynamically 
allow-invite-users-dynamically 
allow-remove-users-dynamically 
from-mixer 

join-handling 
user-admission-policy 


deny-users-list 
floor-information 
conference-time 


floor 

entry 
mixing-start-offset 
mixing-end-offset 
can-join-after-offset 
must-join-before-offset 
request-user 
notify-end-of-conference 
allowed-extend-mixing-end-offset 
codec 

subtype 

mute 


gain 

conference-ID 
floor-request-handling 
media-label 

algorithm 
max-floor-users 
moderator-id 


target 
persistent-list 
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| xcon:e-mail 
| xcon:user) { anyExtension } 
anyExtension = 
(attribute * { text } 
| any)* 
any = 
element * { 
(attribute * { text } 
text 
any) * 


} 


# EXTENSIBILITY ATTRIBUTES 
# 


anyAttribute = 
attribute * - (xml:lang 
| entity 
| required-participant 
| label 
| decision 
name 
policy 
| uri 
| method 
| ia 
| nickname) { text }* 


6. XML Schema Extensibility 


The conference information data model defined in this document is 
meant to be extensible. Extensions are accomplished by defining 
elements or attributes qualified by namespaces other than 
"urn:ietf:params:xml:ns:conference-info" and 
"urn:ietf:params:xml:ns:xcon-conference-info" for use wherever the 
schema allows such extensions (i.e., where the RELAX NG definition 
specifies "anyAttribute" or "anyElement"). 


Elements or attributes from unknown namespaces MUST be ignored. 
7. XML Example 


The following is an example of a conference information document. 


The conference starts on October 17, 2007, at 10:30 a.m. in New York 
City and finishes the same day at 12:30 p.m. every week and repeats 
every week. In this example, there are currently three participants 


in the conference: one administrator, one moderator, and one 
participant. Sidebars are allowed in this conference and, 
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consequently, there is one sidebar in the conference. In addition, 
Alice and Carol are using a floor in the main conference to manage 
the audio and video resources. At the moment, Alice is assigned to 
use the floor. 


<?xml version="1.0" encoding-"UTF-8"?» 
<conference-info 
xmlns="urn:ietf:params:xml:ns:conference-info" 
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" 
entity="conferencel23@example.com"> 
<== 
CONFERENCE DESCRIPTION 


--> 

<conference-description xml:lang="en-us"> 
<display-text>Discussion of Formula-1 racing</display-text> 
<subject>Sports:Formula-1</subject> 
<free-text>This is a conference example</free-text> 
<keywords>Formula-1 cars</keywords> 


UE 
CONFERENCE UNIQUE IDENTIFIERS 
--> 
<conf-uris> 
<entry> 
<uri>tel:+3585671234</uri> 
<display-text>Conference Bridge</display-text> 
<purpose>participation</purpose> 
<xcon:conference-password 
>5678</xcon:conference-password> 
</entry> 
<entry> 
<uri>http://www.example.com/live.ram</uri> 
<purpose>streaming</purpose> 
</entry> 
</conf-uris> 
SL 
SERVICE URIS 
--> 
<service-uris> 
<entry> 
<uri>mailto:bob@example.com</uri> 
<display-text>email</display-text> 
</entry> 
</service-uris> 
Sie 
MAXIMUM USER COUNT 
--> 


<maximum-user-count>50</maximum-user-count> 
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<= 
AVAILABLE MEDIA 
--> 
<available-media> 
<entry label="10234"> 
<display-text>main audio</display-text> 
<type>audio</type> 
<status>sendrecv</status> 
<xcon:mixing-mode>automatic</xcon:mixing-mode> 
<xcon:codecs decision="automatic"> 
<xcon:codec name="122" policy="allowed"> 
<xcon:subtype>PCMU</xcon:subtype> 
</xcon:codec> 
</xcon:codecs> 
<xcon:controls> 
<xcon:mute>true</xcon:mute> 
<xcon:gain>50</xcon:gain> 
</xcon:controls> 
</entry> 
<entry label="10235"> 
<display-text>main video</display-text> 
<type>video</type> 
<status>sendrecv</status> 
<xcon:mixing-mode>automatic</xcon:mixing-mode> 
<xcon:codecs decision="automatic"> 
<xcon:codec name="123" policy="allowed"> 
<xcon:subtype>H.263</xcon:subtype> 
</xcon:codec> 
</xcon:codecs> 
<xcon:controls> 
<xcon:video-layout 
>single-view</xcon:video-layout> 
</xcon:controls> 
</entry> 
</available-media> 


<xcon:language>En-us</xcon:language> 


<xcon:allow-sidebars>true</xcon:allow-sidebars> 
epu 

CONFERENCE TIME 
--> 


<xcon:conference-time> 
<xcon:entry> 
<xcon:base>BEGIN:VCALENDAR 
PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN 
VERSION:2.0 
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BEGIN:VEVENT 
DTSTAMP:20071003T1407282 
UID:20071003T1407282-345FDA-carol@example.com 
ORGANIZER:MAILTO:carol@example.com 
DTSTART:20071017T143000Z 
RRULE: FREQ=WEEKLY 
DTEND:20071217T163000Z 
END : VEVENT 
END : VCALENDAR</xcon:base> 
<xcon:mixing-start-offset 
required-participant="moderator" 
>2007-10-17T14:29:00Z</xcon:mixing-start-offset> 
<xcon:mixing-end-offset 
required-participant="participant" 
>2007-10-17T16:31:00Z</xcon:mixing-end-offset> 
<xcon:must-join-before-offset 
>2007-10-17T15:30:00Z 
</xcon:must-join-before-offset> 


</xcon:entry> 
</xcon:conference-time> 


</conference-description> 
ep 
HOST INFO 
--» 
<host-info> 
<display-text>Formulal</display-text> 
«web-page»http://www.example.com/formulal/«/web-page» 
«uris» 
«entry» 
<uri>sip:alice@example.com</uri> 
</entry> 
<entry> 
<uri>sip:carol@example.com</uri> 
</entry> 
</uris> 
</host-info> 
a 
CONFERENCE STATE 
--» 
«conference-state» 
«user-count»3«/user-count» 
<active>true</active> 
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<locked>false</locked> 
<xcon:allow-conference-event-subscription 
>true</xcon:allow-conference-event-subscription> 


</conference-state> 


<users> 

«I-- 

USER BOB 

--» 

«user entity-"xcon-userid:bob534"» 
<display-text>Bob Hoskins</display-text> 
<associated-aors> 

<entry> 
<uri>mailto:bob@example.com</uri> 
<display-text>email</display-text> 
</entry> 
</associated-aors> 
<roles> 
<entry>participant</entry> 
</roles> 
<languages>en-us</languages> 


«1-- 
ENDPOINTS 
--> 
<endpoint entity="sip:bob@example.com"> 
<display-text>Bob’s Laptop</display-text> 
<referred> 
<when>2007-10-17T14:00:00Z</when> 
<reason>expert required</reason> 
<by>sip:alice@example.com</by> 
</referred> 
<status>connected</status> 
<joining-method>dialed-out</joining-method> 
<joining-info> 
<when>2007-10-17T14:00:00Z</when> 
<reason>invitation</reason> 
<by>sip:alice@example.com</by> 
</joining-info> 
<= 
MEDIA 
--> 
<media id="1"> 
<type>video</type> 
<label>10235</label> 
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<src-id>432424</src-id> 
<status>sendrecv</status> 
<xcon:to-mixer name="VideoIn"> 
<xcon:controls> 
<xcon:video-layout 
>single-view</xcon:video-layout> 
</xcon:controls> 
</xcon:to-mixer> 
</media> 
ep 
CALL INFO 
--» 
<call-info> 
<sip> 
<display-text>full info</display-text> 
<call-id>hsjh8980vhsb78</call-id> 
<from-tag>vav738dvbs</from-tag> 
<to-tag>8954jgjg8432</to-tag> 
</sip> 
</call-info> 
</endpoint> 
<xcon:provide-anonymity 
>semi-private</xcon:provide-anonymity> 
<xcon:allow-refer-users-dynamically 
>false</xcon:allow-refer-users-dynamically> 
<xcon:allow-invite-users-dynamically 
>false</xcon:allow-invite-users-dynamically> 
<xcon:allow-remove-users-dynamically 
>false</xcon:allow-remove-users-dynamically> 
</user> 


Sira 
USER ALICE 

--» 

«user entity="xcon-userid:alice334"> 
<display-text>Alice Kay</display-text> 
<associated-aors> 

<entry> 
<uri>mailto:alice@example.com</uri> 
<display-text>email</display-text> 
</entry> 
</associated-aors> 
<roles> 
<entry>moderator</entry> 
</roles> 
<languages>en-us</languages> 
sies 
ENDPOINTS 
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--» 

«endpoint entity="sip:alice@example.com"> 
<display-text>Alice's Desktop</display-text> 
<status>connected</status> 
<joining-method>dialed-in</joining-method> 
<joining-info> 

<when>2007-10-17T13:35:08Z</when> 
<reason>invitation</reason> 
<by>sip:conference@example.com</by> 
</joining-info> 
«1-- 
MEDIA 
--> 
<media id="1"> 
<type>video</type> 
<label>10235</label> 
«src-id»432424«/src-id» 
<status>sendrecv</status> 
<xcon:to-mixer name="VideoIn"> 
<xcon:controls> 
<xcon:video-layout 
>single-view</xcon:video-layout> 
</xcon:controls> 
</xcon:to-mixer> 
</media> 
<media id="2"> 
<type>audio</type> 
<label>10234</label> 
<src-id>532535</src-id> 
<status>sendrecv</status> 
<xcon:to-mixer name="AudioIn"> 
<xcon:controls> 
<xcon:gain>50</xcon:gain> 
</xcon:controls> 
</xcon:to-mixer> 
«xcon:from-mixer name-"AudioOut"» 
<xcon:controls> 
<xcon:gain>50</xcon:gain> 
</xcon:controls> 
</xcon: from-mixer> 
</media> 
<!-- 
CALL INFO 
--» 
<call-info> 
<sip> 
<display-text>full info</display-text> 
<call-id>truy45469123478</call-id> 
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<from-tag>asd456cbgt</from-tag> 
«to-tag»3456jgjg1234«/to-tag» 
«/sip» 
</call-info> 
«xcon:floor id="345">true</xcon:floor> 
</endpoint> 
<xcon:provide-anonymity>private</xcon:provide-anonymity> 
<xcon:allow-refer-users-dynamically 
>true</xcon:allow-refer-users-dynamically> 
<xcon:allow-invite-users-dynamically 
>true</xcon:allow-invite-users-dynamically> 
<xcon:allow-remove-users-dynamically 
>true</xcon:allow-remove-users-dynamically> 
</user> 


«1-- 
USER CAROL 
--> 
<user entity="xcon-userid:carol233"> 
<display-text>Carol More</display-text> 
<associated-aors> 
<entry> 
<uri>mailto:carol@example.com</uri> 
<display-text>email</display-text> 
</entry> 
</associated-aors> 
<roles> 
<entry>administrator</entry> 
</roles> 
<languages>en-us</languages> 
<= 
ENDPOINTS 
--> 
<endpoint entity="sip:carol@example.com"> 
<display-text>Carol’s Computer</display-text> 
<status>connected</status> 
<joining-method>dialed-in</joining-method> 
<joining-info> 
<when>2007-10-17T13:30:05Z</when> 
<reason>invitation</reason> 
<by>sip:conference@example.com</by> 
</joining-info> 
<= 
MEDIA 
--> 
<media id="1"> 
<type>video</type> 
<label>10235</label> 
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«src-id»432424«/src-id» 
<status>sendrecv</status> 
<xcon:to-mixer name="VideoIn"> 
<xcon:controls> 
<xcon:video-layout 
>single-view</xcon:video-layout> 
</xcon:controls> 
</xcon:to-mixer> 
</media> 
<media id="2"> 
<type>audio</type> 
<label>10234</label> 
<src-id>532535</src-id> 
<status>sendrecv</status> 
<xcon:to-mixer name="AudioIn"> 
<xcon:controls> 
<xcon:gain>50</xcon:gain> 
</xcon:controls> 
</xcon:to-mixer> 
«xcon:from-mixer name-"AudioOut"» 
<xcon:controls> 
<xcon:gain>50</xcon:gain> 
</xcon:controls> 
</xcon: from-mixer> 
</media> 
«1-- 
CALL INFO 
--» 
<call-info> 
<sip> 
<display-text>full info</display-text> 
<call-id>wevb12562321894</call-id> 
<from-tag>asw456wedf</from-tag> 
<to-tag>2365dfrt3497</to-tag> 


</sip> 
</call-info> 


<xcon:floor id="345">false</xcon:floor> 
</endpoint> 


<xcon:provide-anonymity>private</xcon:provide-anonymity> 
<xcon:allow-refer-users-dynamically 
>true</xcon:allow-refer-users-dynamically> 
<xcon:allow-invite-users-dynamically 
>true</xcon:allow-invite-users-dynamically> 
<xcon:allow-remove-users-dynamically 
>true</xcon:allow-remove-users-dynamically> 
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</user> 


<xcon:join-handling>allow</xcon:join-handling> 
<xcon:user-admission-policy 
>openAuthenticated</xcon:user-admission-policy> 
Si == 
ALLOWED USERS LIST 
--> 
<xcon:allowed-users-list> 
<xcon:target uri="sip:bob@example.com" 
method="dial-out"/> 
<xcon:target uri="sip:alice@example.com" 
method="dial-out"/> 
<xcon:target uri="sip:carol@example.com" 
method="dial-out"/> 
<xcon:target uri="sip:john@example.com" 
method="refer"/> 
</xcon:allowed-users-list> 
ede 
DENY USERS LIST 
--> 
<xcon:deny-users-list> 
<xcon:target uri="sip:charlie@example.com"/> 
</xcon:deny-users-list> 
</users> 
=> 
SIDEBARS BY REFERENCE 
--> 
<sidebars-by-ref> 
<entry> 
<uri>xcon:conf223</uri> 
<display-text>private with Bob</display-text> 
</entry> 
</sidebars-by-ref> 
sle 
SIDEBARS BY VALUE 
--> 
<sidebars-by-val> 
<entry entity="conf223"> 
<users> 
<user entity="xcon-userid:bob534"/> 
<user entity="xcon-userid:carol233"/> 
</users> 
</entry> 
</sidebars-by-val> 
Sila 
FLOOR INFORMATION 
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«xcon:floor-information» 
<xcon:conference-ID>567</xcon:conference-ID> 
<xcon:allow-floor-events>true</xcon:allow-floor-events> 
«xcon:floor-request-handling 

>confirm</xcon:floor-request-handling> 


<xcon:conference-floor-policy> 
<xcon: floor id="345"> 
<xcon:media-label>10234</xcon:media-label> 
<xcon:media-label>10235</xcon:media-label> 
<xcon:algorithm 
>moderator-controlled</xcon:algorithm> 
<xcon:max-floor-users>1</xcon:max-floor-users> 
<xcon:moderator-id>234</xcon:moderator-id> 
«/xcon:floor» 
«/xcon:conference-floor-policy» 
«/xcon:floor-information» 


«/conference-info» 


Note that due to RFC formatting conventions, this documents splits 
lines whose content would exceed 72 characters. 


8. Security Considerations 


There are numerous security considerations for this document. 
Overall, the security considerations for authentication and the 
Security and Privacy of Identity described in Sections 11 and 11.2, 
respectively, of the centralized conferencing framework document 
[RFC5239] apply to this document. 


This specification defines a data model for conference objects. 
Different conferencing systems may use different protocols to provide 
access to these conference objects. This section contains general 
security considerations for the conference objects and for the 
protocols. The specification of each particular protocol needs to 
discuss how the specific protocol meets the security requirements 
provided in this section. 


A given conferencing system usually supports different protocols in 
order to implement different functions (e.g., SIP for session control 
and BFCP for floor control). Each of these protocols may use its own 
authentication mechanism. In cases where a user is authenticated 
using multiple authentication mechanisms, it is up to the 
conferencing system to map all the different authentications to the 
same user. Discussing the specifics of different authentication 
mechanism is beyond the scope of this document. 
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Furthermore, users may use different identifiers to access a 
conference, as explained in Section 4.6.5. These different 
namespaces can be associated with a unique conference user identifier 
(XCON-USERID). A mapping database is used to map all these 
authenticated user namespaces to the XCON-USERID. There are several 
threats against this database. In order to minimize these threats, 
the administrator of the conferencing system MUST ensure that only 
authorized users can connect to this database (e.g., by using access 
control rules). In particular, the integrity of the database MUST be 
protected against unauthorized modifications. In addition, the XCON- 
USERID or XCON-URI SHOULD be hard to guess. It is critical that the 
URI remain difficult to "guess" via brute force methods. Generic 
security considerations for usage of URIs are discussed in [RFC3986]. 


It is RECOMMENDED that the database uses encryption mechanisms if the 
information is stored in long-term storage (e.g., disk). If the 
database contains sensitive elements (e.g., passwords), the 
confidentiality of the database MUST be protected from unauthorized 
users. If no sensitive elements are present, then confidentiality is 
not needed. In addition to implementing access control, as discussed 
above, it is RECOMMENDED that administrators of conferencing systems 
only provide access to the database over encrypted channels (e.g., 
using TLS encryption) in order to avoid eavesdroppers. 

Administrators of conferencing systems SHOULD also avoid disclosing 
information to unauthorized parties when a conference is being cloned 
or when a sidebar is being created. For example, an external sidebar 
as defined in [RFC5239], Section 9.4.2, may include participants who 
were not authorized for the parent conference. 


The security considerations for authentication described in Section 
11.1 of the centralized conferencing framework document [RFC5239] 
also apply to this document. Similarly, the security considerations 
for authorization described in Section 5.2 of the Session Initiation 
Protocol (SIP) REFER Method [RFC3515] apply to this document as well. 


Note that the specification of the privacy policy is outside the 
scope of this document. Saying that, a privacy policy will be needed 
in the real implementation of the data model and, therefore, is 
subject to future policy documents. 
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9. IANA Considerations 
9.1. RELAX NG Schema Registration 


This specification registers a schema. The schema can be found 
as the sole content of Section 5. 


URI: urn:ietf:params:xml:schema:xcon-conference-info 


Registrant Contact: IETF XCON working group <xcon@ietf.org>, 
Oscar Novo <Oscar.Novo@ericsson.com> 


RELAX NG Schema: The RELAX NG schema to be registered is contained 
in Section 5. Its first line is as follows: 


default namespace = "urn:ietf:params:xml:ns:conference-info" 
and its last line is as follows: 
anyAttribute = attribute * - (xml:lang | entity 


required-participant | label | decision | name 
| policy | uri | method | id | nickname) ( text }* 
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9.2. XML Namespace Registration 
This section registers a new XML namespace. 
URI: urn:ietf:params:xml:ns:xcon-conference-info 


Registrant Contact: IETF XCON working group <xcon@ietf.org>, 
Oscar Novo <Oscar.Novo@ericsson.com> 


XML: 


BEGIN 

<?xml version="1.0"?> 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> 

<html xmlns="http://www.w3.0rg/1999/xhtml"> 

<head> 
<meta http-equiv="content-type" 

content="text/html;charset=iso-8859-1"/> 

<title> Centralized Conferencing Namespace</title> 

</head> 

<body> 
<h1>Namespace for Centralized Conferencing</h1> 
<h2>urn:ietf:params:xml:ns:xcon-conference-info</h2> 

<p>See <a href-"http://www.rfc-editor.org/rfc/rfc6501.txt"» 
RFC 6501</a>.</p> 

</body> 

</html> 

END 


9.3. Conference Object Identifier Registration 


URI scheme name: xcon 

Status: permanent 

URI scheme syntax: see Section 3.3.1. 

URI schema semantics: see Section 3.3 

Encoding considerations: see Section 8 

Intended usage: see Section 3.3 

Applications and/or protocols that use this URI scheme name: 
Centralized Conferencing systems 

Interoperability considerations: none 

Security considerations: see Section 8 

Relevant publications: conference information data model for 
Centralized Conferencing (XCON) 

Contact: Oscar Novo <oscar.novo@ericsson.com> 

Author/Change controller: Oscar Novo <oscar.novo@ericsson.com> 
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9. 


4. 


10. 


11. 


11: 


Conference User Identifier Registration 


URI scheme name: XCON-USERID 

Status: permanent 

URI scheme syntax: see Section 4.6.5 

URI schema semantics: see Section 4.6.5 

Encoding considerations: see Section 8 

Intended usage: see Section 4.6.3 and 4.6.5 

Applications and/or protocols that use this URI scheme name: 
Centralized Conferencing systems. 

Interoperability considerations: none 

Security considerations: see Section 8 

Relevant publications: conference information data model for 
Centralized Conferencing (XCON) 

Contact: Oscar Novo <oscar.novo@ericsson.com> 

Author/Change controller: Oscar Novo <oscar.novo@ericsson.com> 
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Appendix A. Non-Normative RELAX NG Schema in XML Syntax 


<?xml version="1.0" encoding="UTF-8" ?> 
<grammar 

ns="urn:ietf:params:xml:ns:conference-info" 
xmlns="http://relaxng.org/ns/structure/1.0" 
xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" 
datatypeLibrary="http://www.w3.0rg/2001/XMLSchema-datatypes"> 
<start> 

<element name="conference-info"> 

<ref name="conference-type"/> 

</element> 
</start> 
<!-- 

CONFERENCE TYPE 


--> 
<define name="conference-type"> 
<interleave> 
<attribute name="entity"> 
<text/> 
</attribute> 
<ref name="anyAttribute"/> 
<optional> 
<ref name="conference-description-type"/> 
</optional> 
<optional> 
<element name="host-info"> 
<ref name="host-type"/> 
</element> 
</optional> 
<optional> 
<element name="conference-state"> 
<ref name="conference-state-type"/> 
</element> 
</optional> 
<optional> 
<element name="users"> 
<ref name="users-type"/> 
</element> 
</optional> 
<optional> 
<element name="sidebars-by-ref"> 
<ref name="uris-type"/> 
</element> 
</optional> 
<optional> 
<element name="sidebars-by-val"> 
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<ref name="sidebars-by-val-type"/> 


</element> 
</optional> 
<optional> 


<element name="xcon:floor-information"> 
<ref name="floor-information-type"/> 


</element> 

</optional> 

<zeroOrMore> 

<ref name="anyElement"/> 
</zeroOrMore> 

</interleave> 
</define> 
<!-- 

CONFERENCE DESCRIPTION TYPE 

--» 


«define name-"conference-description-type"» 
«element name="conference-description"> 


«interleave» 

«optional» 

«attribute name="xml:lang"> 
«data type="language"/> 

</attribute> 

</optional> 

<ref name="anyAttribute"/> 

<optional> 

<element name="display-text"> 
<text/> 

</element> 

</optional> 

<optional> 

<element name="subject"> 
<text/> 

</element> 

</optional> 

<optional> 

<element name="free-text"> 
<text/> 

</element> 

</optional> 

<optional> 

<element name="keywords"> 
<list> 
<zeroOrMore> 

<data type="string"/> 

</zeroOrMore> 
</list> 

</element> 
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</optional> 

<optional> 

<element name="conf-uris"> 

<ref name="uris-type"/> 

</element> 

</optional> 

<optional> 

<element name="service-uris"> 
<ref name="uris-type"/> 

</element> 

</optional> 

<optional> 


<element name="maximum-user-count "> 


<data type="int"/> 
</element> 
</optional> 
<optional> 
<element name="available-media"> 


<ref name="conference-media-type"/> 


</element> 
</optional> 
<optional> 
<element name="xcon:language"> 
<data type="language"/> 
</element> 
</optional> 
<optional> 


<element name="xcon:allow-sidebars"> 


<data type="boolean"/> 
</element> 
</optional> 
<optional> 


<element name="xcon:cloning-parent"> 


<data type="anyURI"/> 
</element> 
</optional> 
<optional> 


<element name="xcon:sidebar-parent"> 


<data type="anyURI"/> 
</element> 
</optional> 
<optional> 


<element name="xcon:conference-time"> 
<ref name="conferencetime-type"/> 


</element> 
</optional> 
<zeroOrMore> 
<ref name="anyElement"/> 
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</zeroOrMore> 
</interleave> 
</element> 
</define> 
«1-- 
HOST TYPE 
--> 
<define name="host-type"> 
<interleave> 
<optional> 
<element name="display-text"> 
<text/> 
</element> 
</optional> 
<optional> 
<element name="web-page"> 
<data type="anyURI"/> 
</element> 
</optional> 
<optional> 
<element name="uris"> 
<ref name="uris-type"/> 
</element> 
</optional> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
<ref name="anyAttribute"/> 
</interleave> 


</define> 
[IES 
CONFERENCE STATE TYPE 
--> 
<define name="conference-state-type"> 
<interleave> 
<ref name="anyAttribute"/> 
<optional> 


<element name="user-count"> 
<data type="unsignedInt"/> 
</element> 

</optional> 

<optional> 

<element name="active"> 
<data type="boolean"/> 
</element> 

</optional> 

<optional> 

<element name="locked"> 
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<data type="boolean"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:allow-conference-event-subscription"> 
<data type="boolean"/> 
</element> 
</optional> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
</interleave> 
</define> 
KISS 
CONFERENCE MEDIA TYPE 
--> 
<define name="conference-media-type"> 
<interleave> 
<ref name="anyAttribute"/> 
<zeroOrMore> 
<element name="entry"> 
<ref name="conference-medium-type"/> 
</element> 
</zeroOrMore> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
</interleave> 
</define> 
Shee 
CONFERENCE MEDIUM TYPE 
--> 
<define name="conference-medium-type"> 
<interleave> 
<attribute name="label"> 
<text/> 
</attribute> 
<ref name="anyAttribute"/> 
<optional> 
<element name="display-text"> 
<text/> 
</element> 
</optional> 
<optional> 
<element name="type"> 
<text/> 
</element> 
</optional> 
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<optional> 

<element name="status"> 
<ref name="media-status-type"/> 
</element> 

</optional> 

<optional> 

<element name="xcon:mixing-mode"> 
<ref name="mixing-mode-type"/> 
</element> 

</optional> 

<optional> 

<element name="xcon:codecs"> 
<ref name="codecs-type"/> 
</element> 

</optional> 

<optional> 

<element name="xcon:controls"> 
<ref name="control-type"/> 
</element> 

</optional> 

<zeroOrMore> 

<ref name="anyElement"/> 

</zeroOrMore> 

</interleave> 


</define> 
gies 


URIs TYPE 


--> 
<define name="uris-type"> 


<interleave> 

<ref name="anyAttribute"/> 

<zeroOrMore> 

<element name="entry"> 
<ref name="uri-type"/> 
</element> 

</zeroOrMore> 

<zeroOrMore> 

<ref name="anyElement"/> 

</zeroOrMore> 

</interleave> 


</define> 
ES 


URI TYPE 


--> 
<define name="uri-type"> 


<interleave> 
<element name="uri"> 
<data type="anyURI"/> 
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</element> 

<optional> 

<element name="display-text"> 
<text/> 

</element> 

</optional> 

<optional> 

<element name="purpose"> 
<text/> 

</element> 

</optional> 

<optional> 

<element name="modified"> 
<ref name="execution-type"/> 
</element> 

</optional> 

<zeroOrMore> 


<element name="xcon:conference-password"> 


<text/> 
</element> 
</zeroOrMore> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
<ref name="anyAttribute"/> 


</interleave> 


</define> 
stes 


USERS TYPE 


--> 
<define name="users-type"> 


<interleave> 

<ref name="anyAttribute"/> 

<zeroOrMore> 

<element name="user"> 
<ref name="user-type"/> 
</element> 

«/zeroOrMore» 

«optional» 


«element name="xcon:join-handling"> 
«ref name-"join-handling-type"/» 


</element> 
</optional> 
<optional> 


<element name="xcon:user-admission-policy"> 
<ref name="user-admission-policy-type"/> 


</element> 
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</optional> 
<optional> 
<element name="xcon:allowed-users-list"> 
<ref name="allowed-users-list-type"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:deny-users-list"> 
<ref name="deny-user-list-type"/> 
</element> 
</optional> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
</interleave> 
</define> 
«1-- 
USER TYPE 
--> 
<define name="user-type"> 
<interleave> 
<attribute name="entity"> 
<data type="anyURI"/> 
</attribute> 
<ref name="anyAttribute"/> 
<optional> 
<element name="display-text"> 
<text/> 
</element> 
</optional> 
<optional> 
<element name="associated-aors"> 
<ref name="uris-type"/> 
</element> 
</optional> 
<optional> 
<element name="roles"> 
<oneOrMore> 
<element name="entry"> 
<ref name="single-role-type"/> 
</element> 
</oneOrMore> 
</element> 
</optional> 
<optional> 
<element name="languages"> 
<list> 
<data type="language"/> 


Novo, et al. Standards Track [Page 63] 


RFC 6501 Data Model Schema 


</list> 

</element> 

</optional> 

<optional> 

<element name="cascaded-focus"> 
<data type="anyURI"/> 
</element> 

</optional> 

<zeroOrMore> 

<element name="endpoint"> 
<ref name="endpoint-type"/> 
</element> 

</zeroOrMore> 

<optional> 


<element name="xcon:provide-anonymity"> 


<ref name="provide-anonymity-type"/> 
</element> 

</optional> 

<optional> 


March 2012 


<element name="xcon:allow-refer-users-dynamically"> 


<data type="boolean"/> 
</element> 
</optional> 
<optional> 


<element name="xcon:allow-invite-users-dynamically"> 


<data type="boolean"/> 
</element> 
</optional> 
<optional> 


<element name="xcon:allow-remove-users-dynamically"> 


<data type="boolean"/> 
</element> 
</optional> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
</interleave> 
</define> 
«1-- 
ENDPOINT TYPE 
--» 
«define name-"endpoint-type"» 
«interleave» 
«attribute name-"entity"» 
«text/» 
</attribute> 
<ref name="anyAttribute"/> 
<optional> 
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<element name="display-text"> 
<text/> 

</element> 

</optional> 

<optional> 

<element name="referred"> 
<ref name="execution-type"/> 

</element> 

</optional> 

<optional> 

<element name="status"> 
<ref name="endpoint-status-type"/> 

</element> 

</optional> 

<optional> 

<element name="joining-method"> 
<ref name="joining-type"/> 

</element> 

</optional> 

<optional> 

<element name="joining-info"> 
<ref name="execution-type"/> 

</element> 

</optional> 

<optional> 

<element name="disconnection-method"> 
<ref name="disconnection-type"/> 

</element> 

</optional> 

<optional> 

<element name="disconnection-info"> 
<ref name="execution-type"/> 

</element> 

</optional> 

<zeroOrMore> 

<element name="media"> 
<ref name="media-type"/> 

</element> 

</zeroOrMore> 

<optional> 

<element name="call-info"> 
<ref name="call-type"/> 

</element> 

</optional> 

<zeroOrMore> 

<ref name="anyElement"/> 

</zeroOrMore> 

</interleave> 
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</define> 
spe 
ENDPOINT STATUS TYPE 
--> 
<define name="endpoint-status-type"> 
<choice> 


<value>pending</value> 
<value>dialing-out</value> 
<value>dialing-in</value> 
<value>alerting</value> 
<value>on-hold</value> 
<value>connected</value> 
<value>muted-via-focus</value> 
<value>disconnecting</value> 
<value>disconnected</value> 

<ref name="free-text-extension"/> 


</choice> 
</define> 
d 
JOINING TYPE 
--> 
<define name="joining-type"> 
<choice> 


<value>dialed-in</value> 
<value>dialed-out</value> 
<value>focus-owner</value> 

<ref name="free-text-extension"/> 


</choice> 
</define> 
<I> 
DISCONNECTION TYPE 
--> 
<define name="disconnection-type"> 
<choice> 


<value>departed</value> 
<value>booted</value> 
<value>failed</value> 
<value>busy</value> 
<ref name="free-text-extension"/> 
</choice> 
</define> 
«1-- 
EXECUTION TYPE 
--> 
<define name="execution-type"> 
<interleave> 
<optional> 
<element name="when"> 
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<data type="dateTime"/> 
</element> 
</optional> 
<optional> 
<element name="reason"> 
<text/> 
</element> 
</optional> 
<optional> 
<element name="by"> 
<data type="anyURI"/> 
</element> 
</optional> 
<ref name="anyAttribute"/> 
</interleave> 
</define> 
«1-- 
CALL TYPE 
--> 
<define name="call-type"> 
<interleave> 
<element name="sip"> 


<ref name="sip-dialog-id-type"/> 


</element> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
<ref name="anyAttribute"/> 
</interleave> 
</define> 
«1-- 
SIP DIALOG ID TYPE 
--» 
«define name-"sip-dialog-id-type"» 


«interleave» 

«optional» 

<element name="display-text"> 
«text/» 

«/element» 

«/optional» 

«element name="call-id"> 
«text/» 

«/element» 

«element name="from-tag"> 
«text/» 

</element> 
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<element name="to-tag"> 
<text/> 
</element> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
<ref name="anyAttribute"/> 
</interleave> 
</define> 
qs 
MEDIA TYPE 
--> 
<define name="media-type"> 
<interleave> 
<attribute name="id"> 
<data type="int"/> 
</attribute> 
<ref name="anyAttribute"/> 
<optional> 
<element name="display-text"> 
<text/> 
</element> 
</optional> 
<optional> 
<element name="type"> 
<text/> 
</element> 
</optional> 
<optional> 
<element name="label"> 
<text/> 
</element> 
</optional> 
<optional> 
<element name="src-id"> 
<text/> 
</element> 
</optional> 
<optional> 
<element name="status"> 
<ref name="media-status-type"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:to-mixer"> 
<ref name="mixer-type"/> 
</element> 
</optional> 
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<optional> 

<element name="xcon:from-mixer"> 
<ref name="mixer-type"/> 
</element> 

</optional> 

<zeroOrMore> 

<ref name="anyElement"/> 

</zeroOrMore> 

</interleave> 


</define> 
ede 


MEDIA STATUS TYPE 


--> 
<define name="media-status-type"> 


<choice> 

<value>recvonly</value> 
<value>sendonly</value> 
<value>sendrecv</value> 
<value>inactive</value> 

<ref name="free-text-extension"/> 
</choice> 


</define> 
sies 


SIDEBARS-BY-VAL TYPE 


--» 


«define name-"sidebars-by-val-type"» 


<interleave> 

<ref name="anyAttribute"/> 

<zeroOrMore> 

<element name="entry"> 
<ref name="conference-type"/> 
</element> 

</zeroOrMore> 

<zeroOrMore> 

<ref name="anyElement"/> 

</zeroOrMore> 

</interleave> 


</define> 
epe 


CONFERENCE TIME 


=-> 
<define name="conferencetime-type"> 


et al. 


<interleave> 

<ref name="anyAttribute"/> 

<zeroOrMore> 

<element name="xcon:entry"> 
<element name="xcon:base"> 
<text/> 
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</element> 

<optional> 

<element name="xcon:mixing-start-offset"> 
<ref name="time-type"/> 
<attribute name="required-participant"> 
<ref name="single-role-type"/> 


</attribute> 

<ref name="anyAttribute"/> 
</element> 
</optional> 
<optional> 


<element name="xcon:mixing-end-offset"> 
<ref name="time-type"/> 

<attribute name="required-participant"> 
<ref name="single-role-type"/> 


</attribute> 

<ref name="anyAttribute"/> 
</element> 
</optional> 
<optional> 


<element name="xcon:can-join-after-offset"> 
<ref name="time-type"/> 

</element> 

</optional> 

<optional> 

<element name="xcon:must-join-before-offset"> 
<ref name="time-type"/> 

</element> 

</optional> 

<optional> 

<element name="xcon:request-user"> 
<ref name="time-type"/> 

</element> 

</optional> 

<optional> 

<element name="xcon:notify-end-of-conference"> 
<data type="nonNegativeInteger"/> 

</element> 

</optional> 

<optional> 


2012 


<element name="xcon:allowed-extend-mixing-end-offset"> 


<data type="boolean"/> 
</element> 
</optional> 
<zeroOrMore> 
«ref name="anyElement"/> 
</zeroOrMore> 
</element> 
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</zeroOrMore> 
</interleave> 
</define> 
USES 
TIME TYPE 
--> 
<define name="time-type"> 
<data type="dateTime"> 


<param name="pattern">.+T.+2.*</param> 


</data> 
</define> 
aa 

SINGLE ROLE TYPE 

--> 
<define name="single-role-type"> 
<choice> 

<value type="string">none</value> 


<value type="string">administrator</value> 
<value type="string">moderator</value> 


<value type="string">user</value> 


<value type="string">observer</value> 
<value type="string">participant</value> 


<ref name="free-text-extension"/> 

</choice> 

</define> 

<!-- 

MIXING MODE TYPE 

--» 

«define name="mixing-mode-type"> 
«choice» 


«value type="string">moderator-controlled</value> 


«value type="string">FCFS</value> 


«value type="string">automatic</value> 


«ref name-"free-text-extension"/» 
«/choice» 
«/define» 
<!-- 
CODECS TYPE 
--» 
«define name="codecs-type"> 
«interleave» 
«attribute name-"decision"» 
«ref name-"decision-type"/» 
</attribute> 
<ref name="anyAttribute"/> 
<zeroOrMore> 
<element name="xcon:codec"> 
<ref name="codec-type"/> 
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</element> 
</zeroOrMore> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
</interleave> 
</define> 
xb 
CODEC TYPE 
--> 
<define name="codec-type"> 
<interleave> 
<attribute name="name"> 
<text/> 
</attribute> 
<attribute name="policy"> 
<ref name="policy-type"/> 
</attribute> 
<ref name="anyAttribute"/> 
<optional> 
<element name="xcon:subtype"> 
<text/> 
</element> 
</optional> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
</interleave> 
</define> 
«1-- 
DECISION TYPE 
--> 
<define name="decision-type"> 
<choice> 


<value type="string">automatic</value> 
<value type="string">moderator-controlled</value> 
<ref name="free-text-extension"/> 


</choice> 
</define> 
<= 
POLICY TYPE 
--> 
<define name="policy-type"> 
<choice> 


<value type="string">allowed</value> 
<value type="string">disallowed</value> 
<ref name="free-text-extension"/> 


</choice> 
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</define> 
epe 
CONTROL TYPE 
--> 
<define name="control-type"> 
<interleave> 
<ref name="anyAttribute"/> 
<optional> 
<element name="xcon:mute"> 
<data type="boolean"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:pause-video"> 
<data type="boolean"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:gain"> 
<ref name="gain-type"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:video-layout"> 
<ref name="video-layout-type"/> 
</element> 
</optional> 


<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
</interleave> 
</define> 
xp 
GAIN TYPE 
--> 
<define name="gain-type"> 
<data type="int"> 


<param name="minInclusive">-127</param> 
<param name="maxInclusive">127</param> 


</data> 
</define> 
SIR 
VIDEO LAYOUT TYPE 
--» 
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<define name="video-layout-type"> 
<choice> 
<value type="string">single-view</value> 
<value type="string">dual-view</value> 
<value type="string">dual-view-crop</value> 
<value type="string">dual-view-2x1</value> 
<value type="string">dual-view-2x1-crop</value> 
<value type="string">quad-view</value> 
<value type="string">multiple-3x3</value> 
<value type="string">multiple-4x4</value> 
<value type="string">multiple-5x1</value> 
<value type="string">automatic</value> 
<ref name="free-text-extension"/> 
</choice> 
</define> 
«1-- 
FLOOR INFORMATION TYPE 
--» 
«define name-"floor-information-type"» 
<interleave> 
<ref name="anyAttribute"/> 
<optional> 
<element name="xcon:conference-ID"> 
<data type="unsignedLong"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:allow-floor-events"> 
<data type="boolean"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:floor-request-handling"> 
<ref name="floor-request-type"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:conference-floor-policy"> 
<ref name="conference-floor-policy"/> 
</element> 
</optional> 
<zeroOrMore> 
<ref name="anyElement"/> 
</zeroOrMore> 
</interleave> 
</define> 
«1-- 
FLOOR REQUEST TYPE 
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--» 
«define name="floor-request-type"> 
«choice» 
«value type="string">block</value> 
«value type="string">confirm</value> 
«ref name-"free-text-extension"/» 
«/choice» 
«/define» 
«1-- 
CONFERENCE FLOOR POLICY 
--» 
«define name-"conference-floor-policy"» 
«interleave» 
«ref name-"anyAttribute"/» 
«oneOrMore» 
«element name="xcon:floor"> 
«interleave» 
«attribute name-"id"» 
«text/» 
</attribute> 
<ref name="anyAttribute"/> 
<oneOrMore> 
<element name="xcon:media-label"> 
<data type="nonNegativeInteger"/> 
</element> 
</oneOrMore> 
<optional> 
<element name="xcon:algorithm"> 
<ref name="algorithm-type"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:max-floor-users"> 
<data type="nonNegativeInteger"/> 
</element> 
</optional> 
<optional> 
<element name="xcon:moderator-id"> 
<data type="nonNegativeInteger"/> 
</element> 
</optional> 
<zeroOrMore> 
<ref name="anyElement"/> 
«/zeroOrMore» 
«/interleave» 
«/element» 
</oneOrMore> 
</interleave> 
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</define> 
sites 
ALGORITHM POLICY 
--> 
<define name="algorithm-type"> 
<choice> 


<value type="string">moderator-controlled</value> 
<value type="string">FCFS</value> 

<value type="string">random</value> 

<ref name="free-text-extension"/> 


</choice> 
</define> 
<!-- 
USERS ADMISSION POLICY 
--> 
<define name="user-admission-policy-type"> 
<choice> 


<value type="string">closedAuthenticated</value> 
<value type="string">openAuthenticated</value> 
<value type="string">anonymous</value> 

<ref name="free-text-extension"/> 


</choice> 
</define> 
qlee 
JOIN HANDLING TYPE 
--> 
<define name="join-handling-type"> 
<choice> 


<value type="string">block</value> 
<value type="string">confirm</value> 
<value type="string">allow</value> 
<value type="string">authenticate</value> 
<value type="string">directed-operator</value> 
<ref name="free-text-extension"/> 
</choice> 
</define> 
eL 
DENY USERLIST 
=-> 
«define name-"deny-user-list-type"» 
<interleave> 
<ref name="anyAttribute"/> 
<zeroOrMore> 
<element name="xcon:target"> 
<attribute name="uri"> 
<data type="anyURI"/> 
</attribute> 
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<ref name="anyAttribute"/> 

</element> 
</zeroOrMore> 
<zeroOrMore> 

<ref name="anyElement"/> 
</zeroOrMore> 
</interleave> 
</define> 
<!-- 

ALLOWED USERS LIST TYPE 

--» 


«define name-"allowed-users-list-type"» 


«interleave» 
«ref name-"anyAttribute"/» 
«zeroOrMore» 


«element name="xcon:target"> 


«ref name-"target-type"/» 
</element> 
</zeroOrMore> 
<optional> 


<element name="xcon:persistent-list"> 
«ref name-"persistent-list-type"/» 


«/element» 
«/optional» 
«zeroOrMore» 

«ref name-"anyElement"/» 
«/zeroOrMore» 
«/interleave» 

«/define» 
«1-- 

PERSISTENT LIST TYPE 
--» 


«define name-"persistent-list-type"» 


«interleave» 
<zeroOrMore> 


<element name="xcon:user"> 


<interleave> 

<attribute name="name"> 
<text/> 

</attribute> 


<attribute name="nickname"> 


<text/> 

</attribute> 
<attribute name="id"> 
<text/> 

</attribute> 


<ref name="anyAttribute"/> 


<zeroOrMore> 
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<element name="xcon:e-mail"> 


<text/> 
</element> 
</zeroOrMore> 
<zeroOrMore> 


<ref name="anyElement"/> 


«/zeroOrMore» 
«/interleave» 
«/element» 
«/zeroOrMore» 
«zeroOrMore» 
«ref name-"anyElement"/» 
«/zeroOrMore» 
«/interleave» 
«/define» 
«1-- 
TARGET TYPE 
--> 
<define name="target-type"> 
<attribute name="uri"> 
<data type="anyURI"/> 
</attribute> 
<attribute name="method"> 
<ref name="method-type"/> 
</attribute> 
<ref name="anyAttribute"/> 
</define> 
«1-- 
METHOD TYPE 
--> 
<define name="method-type"> 
<choice> 


<value type="string">dial-in</value> 
<value type="string">dial-out</value> 
<value type="string">refer</value> 
<ref name="free-text-extension"/> 


</choice> 
</define> 
sp 

ANONYMITY TYPE 
--» 


«define name="provide-anonymity-type"> 


«choice» 
<value>private</value> 


<value>semi-private</value> 


<value>hidden</value> 


<ref name="free-text-extension"/> 


</choice> 
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</choice> 
</define> 
<br 
FREE TEXT EXTENSION 

--» 

«define name="free-text-extension"> 
«text/» 

«/define» 

Novo, et al. Standards Track 


Data Model Schema 


«/define» 
spe 
MIXER TYPE 
--> 
<define name="mixer-type"> 
<interleave> 
<attribute name="name"> 
<ref name="mixer-name-type"/> 
</attribute> 


<ref name="anyAttribute"/> 

<zeroOrMore> 
<element name="xcon:floor"> 
<attribute name="id"> 

<text/> 

</attribute> 
<ref name="anyAttribute"/> 
<data type="boolean"/> 
</element> 

</zeroOrMore> 

<zeroOrMore> 
<element name="xcon:controls"> 
<ref name="control-type"/> 
</element> 

«/zeroOrMore» 

«zeroOrMore» 
«ref name-"anyElement"/» 

«/zeroOrMore» 

«/interleave» 

«/define» 

«1-- 

MIXER NAME TYPE 

--» 

«define name-"mixer-name-type"» 
«choice» 
<value>VideoIn</value> 
<value>Video0ut</value> 
<value>Audio0ut</value> 
<value>AudioIn</value> 


<ref name="free-text-extension"/> 
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GA Ka 
KKAKKKAKKAKAKAKAKAAKAKAAKAAKAAKAAKAAAKAAKAAAAAAAAA 


EXTENSIBILITY OF THE SCHEMA 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


--> 
ie 
EXTENSIBILITY ELEMENTS 
--> 
<define name="anyElement"> 
<element> 
<anyName> 
<except> 


<name>conference-description</name> 
<name>host-info</name> 
<name>conference-state</name> 
<name>users</name> 
<name>sidebars-by-ref</name> 
<name>sidebars-by-val</name> 
<name>display-text</name> 
<name>subject</name> 
<name>free-text</name> 
<name>keywords</name> 
<name>conf-uris</name> 
<name>service-uris</name> 
<name>maximum-user-count</name> 
<name>available-media</name> 
<name>web-page</name> 
<name>uris</name> 
<name>uri</name> 
<name>user-count</name> 
<name>active</name> 
<name>locked</name> 
<name>entry</name> 
<name>type</name> 
<name>status</name> 
<name>purpose</name> 
<name>modified</name> 
<name>user</name> 
<name>associated-aors</name> 
<name>roles</name> 
<name>languages</name> 
<name>cascaded-focus</name> 
<name>endpoint</name> 
<name>referred</name> 
<name>joining-method</name> 
<name>joining-info</name> 
<name>disconnection-method</name> 
<name>disconnection-info</name> 
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<name>media</name> 

<name>call-info</name> 

<name>when</name> 

<name>reason</name> 

<name>by</name> 

<name>sip</name> 

<name>call-id</name> 

<name>from-tag</name> 

<name>to-tag</name> 

<name>label</name> 

<name>src-id</name> 
<name>xcon:conference-password</name> 
<name>xcon:mixing-mode</name> 
<name>xcon:codecs</name> 
<name>xcon:controls</name> 
<name>xcon:language</name> 
<name>xcon:allow-sidebars</name> 
<name>xcon:cloning-parent</name> 
<name>xcon:sidebar-parent</name> 
<name>xcon:allow-conference-event-subscription</name> 
<name>xcon:to-mixer</name> 
<name>xcon:provide-anonymity</name> 
<name>xcon:allow-refer-users-dynamically</name> 
<name>xcon:allow-invite-users-dynamically</name> 
<name>xcon:allow-remove-users-dynamically</name> 
<name>xcon : from-mixer</name> 

<name>xcon: join-handling</name> 
<name>xcon:user-admission-policy</name> 
<name>xcon:allowed-users-list</name> 
<name>xcon:deny-users-list</name> 
<name>xcon:floor-information</name> 
<name>xcon:conference-time</name> 
<name>xcon:provide-anonymity</name> 

<name>xcon: floor</name> 

<name>xcon:entry</name> 
<name>xcon:mixing-start-offset</name> 
<name>xcon:mixing-end-offset</name> 
«name»xcon:can-join-after-offset«/name» 
«name»xcon:must-join-before-offset«/name» 
<name>xcon:request-user</name> 
<name>xcon:notify-end-of-conference</name> 
<name>xcon:allowed-extend-mixing-end-offset</name> 
<name>xcon:codec</name> 
<name>xcon:subtype</name> 
<name>xcon:mute</name> 
<name>xcon:pause-video</name> 
<name>xcon:gain</name> 
<name>xcon:video-layout</name> 
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<name>xcon: 
<name>xcon: 
<name>xcon: 
<name>xcon: 
<name>xcon: 
:algorithm</name> 
<name>xcon: 
:moderator-id«/name» 


<name>xcon 


<name>xcon 


<name>xcon: 
:persistent-list</name> 
<name>xcon: 


<name>xcon 


Data Model Schema March 


conference-ID</name> 
allow-floor-events</name> 
floor-request-handling</name> 
conference-floor-policy</name> 
media-label</name> 


max-floor-users</name> 
target</name> 


e-mail</name> 


2012 


<name>xcon:user</name> 
</except> 
</anyName> 
<ref name="anyExtension"/> 
</element> 
</define> 


<define name="anyExtension"> 
<zeroOrMore> 
<choice> 
<attribute> 
<anyName/> 
</attribute> 
<ref name="any"/> 
</choice> 
</zeroOrMore> 
</define> 


<define name="any"> 
<element> 
<anyName/> 
<zeroOrMore> 
<choice> 
<attribute> 
<anyName/> 
</attribute> 
<text/> 
<ref name="any"/> 
</choice> 
«/zeroOrMore» 
«/element» 
«/define» 


Sen 
EXTENSIBILITY ATTRIBUTES 
--> 
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<define name="anyAttribute"> 


<zeroOrMore> 
<attribute> 
<anyName> 
<except> 
<name ns="http://www.w3.org/XML/1998/namespace">lang 
</name> 
<name ns="">entity</name> 
<name ns="">required-participant</name> 
<name ns="">label</name> 
<name ns="">decision</name> 
<name ns="">name</name> 
<name ns="">policy</name> 
<name ns="">uri</name> 
<name ns="">method</name> 
<name ns="">id</name> 
<name ns="">nickname</name> 
</except> 
</anyName> 
</attribute> 
</zeroOrMore> 
</define> 
</grammar> 
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Appendix B.  Non-Normative W3C XML Schema 


The non-normative W3C XML schema defines extension elements in the 
"urn:ietf:params:xml:ns:xcon-conference-info" namespace. Note that 
«xs:any» extensions in this schema are stricter than in the normative 
RELAX NG schema [RELAX], and the normative RELAX NG schema [RELAX] 
allows unordered child elements unlike this schema (and the [RFC4575] 
schema). Also, note that this schema allows otherwise valid 
extension elements to appear in the non-allowed positions. Likewise, 
the cardinalities of these extension elements cannot be constrained 
with this schema. 


«?xml version="1.0" encoding-"UTF-8"?» 
«xs:schema 
xmlns-"urn:ietf:params:xml:ns:xcon-conference-info" 
xmlns:info-"urn:ietf:params:xml:ns:conference-info" 
xmlns:xs-"http://www.w3.org/2001/XMLSchema" 
attributeFormDefault-"unqualified" elementFormDefault-"qualified" 
targetNamespace-"urn:ietf:params:xml:ns:xcon-conference-info"» 


«xs:import namespace-"urn:ietf:params:xml:ns:conference-info" 
schemaLocation="rfc4575.xsd"/> 


<xs:import namespace="http://www.w3.org/XML/1998/namespace" 
schemaLocation="http://www.w3.0rg/2001/03/xml.xsd"/> 


<xs:element name="mixing-mode" type="mixing-mode-type"/> 

<xs:element name="codecs" type="codecs-type"/> 

<xs:element name="conference-password" type="xs:string"/> 

<xs:element name="controls" type="controls-type"/> 

<xs:element name="language" type="xs:language"/> 

<xs:element name="allow-sidebars" type="xs:boolean"/> 

<xs:element name="cloning-parent" type="xs:anyURI"/> 

<xs:element name="sidebar-parent" type="xs:anyURI"/> 

<xs:element name="conference-time" type="conference-time-type"/> 

<xs:element name="allow-conference-event-subscription" 
type="xs:boolean"/> 

<xs:element name="to-mixer" type="mixer-type"/> 

<xs:element name="provide-anonymity" 
type="provide-anonymity-type"/> 

<xs:element name="allow-refer-users-dynamically" 
type="xs:boolean"/> 

<xs:element name="allow-invite-users-dynamically" 
type="xs:boolean"/> 

<xs:element name="allow-remove-users-dynamically" 
type="xs:boolean"/> 

<xs:element name="from-mixer" type="mixer-type"/> 

<xs:element name="join-handling" type="join-handling-type"/> 
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<xs:element name="user-admission-policy" 
type="user-admission-policy-type"/> 

<xs:element name="allowed-users-list" 
type="allowed-users-list-type"/> 

<xs:element name="deny-users-list" type="deny-users-list-type"/> 

<xs:element name="floor-information" type="floor-information-type"/> 


<!-- CONFERENCE TIME --> 


<xs:complexType name="conference-time-type"> 
<xs : sequence> 
<xs:element name="entry" 
minOccurs="0" maxOccurs="unbounded"> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="base" 
type="xs:string" minOccurs="1"/> 
<xs:element name="mixing-start-offset" minOccurs="0"> 
<xs:complexType> 
<xs:simpleContent> 
<xs:extension base="time-type"> 
<xs:attribute name="required-participant" 
type="role-type" use="required"/> 
<xs:anyAttribute namespace="##any" 
processContents="lax"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 
</xs:element> 
<xs:element name="mixing-end-offset" minOccurs="0"> 
<xs:complexType> 
<xs:simpleContent> 
<xs:extension base="time-type"> 
<xs:attribute name="required-participant" 
type="role-type" use="required"/> 
<xs:anyAttribute namespace="##any" 
processContents="lax"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 
</xs:element> 
<xs:element name="can-join-after-offset" type="time-type" 
minOccurs="0"/> 
<xs:element name="must-join-before-offset" 
type="time-type" minOccurs="0"/> 
<xs:element name="request-user" type="time-type" 
minOccurs="0"/> 
<xs:element name="notify-end-of-conference" 
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type="xs:nonNegativelnteger" minOccurs="0"/> 
<xs:element name="allowed-extend-mixing-end-offset" 
type="xs:boolean" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- TIME TYPE --> 


<xs:simpleType name="time-type"> 

<xs:restriction base="xs:dateTime"> 
<xs:pattern value=".+T.+Z.*"/> 
</xs:restriction> 

</xs:simpleType> 


<!-- ROLE-TYPE --> 


<xs:simpleType name="role-type"> 
<xs:restriction base="xs:string"> 
<xs:pattern value="none"/> 
<xs:pattern value="administrator"/> 
<xs:pattern value="moderator"/> 
<xs:pattern value="user"/> 
<xs:pattern value="observer"/> 
<xs:pattern value="participant"/> 
<xs:pattern value=".+"/> 
</xs:restriction> 

</xs:simpleType> 


<!-- MIXING MODE TYPE --> 


<xs:simpleType name="mixing-mode-type"> 
<xs:restriction base="xs:string"> 
«xs:pattern value-"moderator-controlled"/» 
«xs:pattern value-"FCFS"/» 
«xs:pattern value-"automatic"/» 
«xs:pattern value=".+"/> 
«/xs:restriction» 
«/xs:simpleType» 


<!-- CODECS TYPE --> 
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<xs:complexType name="codecs-type"> 
<xs:sequence> 
<xs:element name="codec" type="codec-type"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:attribute name="decision" 
type="decision-type" use="required"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- CODEC TYPE --> 


<xs:complexType name="codec-type"> 
<xs:sequence> 
<xs:element name="subtype" type="xs:string" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:attribute name="name" 
type="xs:string" use="required"/> 
<xs:attribute name="policy" 
type="policy-type" use="required"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- DECISION TYPE --> 


<xs:simpleType name="decision-type"> 
<xs:restriction base="xs:string"> 
<xs:pattern value="automatic"/> 
«xs:pattern value-"moderator-controlled"/» 
«xs:pattern value=".+"/> 
</xs:restriction> 
</xs:simpleType> 


<!-- POLICY TYPE --> 


<xs:simpleType name="policy-type"> 

<xs:restriction base="xs:string"> 
<xs:pattern value="allowed"/> 
<xs:pattern value="disallowed"/> 
<xs:pattern value=".+"/> 

</xs:restriction> 

</xs:simpleType> 


<!-- CONTROL TYPE --> 
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<xs:complexType name="controls-type"> 
<xs:sequence> 

<xs:element name="mute" 
type="xs:boolean" minOccurs="0"/> 

<xs:element name="pause-video" 
type="xs:boolean" minOccurs="0"/> 

<xs:element name="gain" 
type="gain-type" minOccurs="0"/> 

<xs:element name="video-layout" 
type="video-layout-type" default="single-view" minOccurs="0"/> 


<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- GAIN TYPE --> 


<xs:simpleType name="gain-type"> 
<xs:restriction base="xs:integer"> 
<xs:minInclusive value="-127"/> 
<xs:maxInclusive value="127"/> 
</xs:restriction> 
</xs:simpleType> 


<!-- VIDEO LAYOUT TYPE --> 


<xs:simpleType name="video-layout-type"> 
<xs:restriction base="xs:string"> 

<xs:pattern value="single-view"/> 
<xs:pattern value="dual-view"/> 
<xs:pattern value="dual-view-crop"/> 
<xs:pattern value="dual-view-2x1"/> 
<xs:pattern value="dual-view-2x1-crop"/> 
<xs:pattern value="quad-view"/> 
<xs:pattern value="multiple-3x3"/> 
<xs:pattern value="multiple-4x4"/> 


<xs:pattern value="multiple-5x1"/> 
<xs:pattern value="automatic"/> 
<xs:pattern value=".+"/> 
</xs:restriction> 
</xs:simpleType> 


<!-- FLOOR INFORMATION TYPE --> 
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<xs:complexType name="floor-information-type"> 
<xs:sequence> 
<xs:element name="conference-ID" 
type="xs:unsignedLong" minOccurs="0"/> 
<xs:element name="allow-floor-events" 
type="xs:boolean" default="false" minOccurs="0"/> 
<xs:element name="floor-request-handling" 
type="floor-request-handling-type" minOccurs="0"/> 
<xs:element name="conference-floor-policy" 
type="conference-floor-policy" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs-"unbounded"/» 
</xs:sequence> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- FLOOR REQUEST TYPE --> 


<xs:simpleType name="floor-request-handling-type"> 
<xs:restriction base="xs:string"> 
<xs:pattern value="block"/> 
<xs:pattern value="confirm"/> 
<xs:pattern value=".+"/> 
</xs:restriction> 
</xs:simpleType> 


<!-- CONFERENCE FLOOR POLICY --> 


<xs:complexType name="conference-floor-policy"> 
<xs : sequence> 
<xs:element name="floor" maxOccurs="unbounded"> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="media-label" 
type="xs:string" minOccurs="1" maxOccurs="unbounded"/> 
<xs:element name="algorithm" 
type="algorithm-type" minOccurs="0"/> 
<xs:element name="max-floor-users" 
type="xs:nonNegativelnteger" minOccurs="0"/> 
<xs:element name="moderator-id" 
type="xs:nonNegativelnteger" minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:attribute name="id" type="xs:string" use="required"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 
</xs:element> 
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</xs:sequence> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- ALGORITHM TYPE --> 


<xs:simpleType name="algorithm-type"> 
<xs:restriction base="xs:string"> 
<xs:pattern value="moderator-controlled"/> 
<xs:pattern value="FCFS"/> 
<xs:pattern value="random"/> 
<xs:pattern value=".+"/> 
</xs:restriction> 
</xs:simpleType> 


<!-- USER ADMISSION POLICY TYPE --> 


<xs:simpleType name="user-admission-policy-type"> 
<xs:restriction base="xs:string"> 
<xs:pattern value="closedAuthenticated"/> 
<xs:pattern value="openAuthenticated"/> 
<xs:pattern value="anonymous"/> 
<xs:pattern value=".+"/> 
</xs:restriction> 
</xs:simpleType> 


<!-- JOIN HANDLING TYPE --> 


<xs:simpleType name="join-handling-type"> 
<xs:restriction base="xs:string"> 
<xs:pattern value="block"/> 
<xs:pattern value="confirm"/> 
<xs:pattern value="allow"/> 
<xs:pattern value="authenticate"/> 
<xs:pattern value="directed-operator"/> 
<xs:pattern value=".+"/> 
</xs:restriction> 
</xs:simpleType> 


<!-- DENY USER LIST TYPE --> 


<xs:complexType name="deny-users-list-type"> 
<xs:sequence> 
<xs:element name="target" minOccurs="0" maxOccurs="unbounded"> 
<xs:complexType> 
<xs:attribute name="uri" use="required" type="xs:anyURI"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 
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</xs:element> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- ALLOWED USERS LIST TYPE --> 


<xs:complexType name="allowed-users-list-type"> 
<xs:sequence> 
<xs:element name="target" type="target-type" 
minOccurs="0" maxOccurs="unbounded"> 
</xs:element> 
<xs:element name="persistent-list" 
type="persistent-list-type" 
minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- PERSISTENT LIST TYPE --> 


<xs:complexType name="persistent-list-type"> 
<xs:sequence> 
<xs:element name="user" minOccurs="0" maxOccurs="unbounded"> 
<xs:complexType> 
<xs:sequence> 
<xs:element name="email" type="xs:string" 
minOccurs="0" maxOccurs="unbounded"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:attribute name="name" 
use="required" type="xs:anyURI"/> 
<xs:attribute name="nickname" 
use="required" type="xs:string"/> 
<xs:attribute name="id" 
use="required" type="xs:string"/> 
<xs:anyAttribute namespace="##any" processContents="lax" 
</xs:complexType> 
</xs:element> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
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</xs:complexType> 
«!-- TARGET TYPE --> 


<xs:complexType name="target-type"> 
<xs:attribute name="uri" use="required" 
type="xs:anyURI"/> 
<xs:attribute name="method" use="required" 
type="method-type"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- METHOD TYPE --> 


<xs:simpleType name="method-type"> 
<xs:restriction base="xs:string"> 
<xs:pattern value="dial-in"/> 
<xs:pattern value="dial-out"/> 
«xs:pattern value="refer"/> 
<xs:pattern value=".+"/> 
</xs:restriction> 
</xs:simpleType> 


<!-- ANONYMITY TYPE --> 


<xs:simpleType name="provide-anonymity-type"> 
<xs:restriction base="xs:string"> 
<xs:pattern value="private"/> 
<xs:pattern value="semi-private"/> 
<xs:pattern value="hidden"/> 
<xs:pattern value=".+"/> 
</xs:restriction> 
</xs:simpleType> 


<!-- MIXER TYPE --> 


<xs:complexType name="mixer-type"> 
<xs:sequence> 
<xs:element name="floor"> 
<xs:complexType> 
<xs:simpleContent> 
<xs:extension base="xs:boolean"> 
<xs:attribute name="id" type="xs:string" 
use="required"/> 
<xs:anyAttribute namespace="##any" 
processContents="lax"/> 
</xs:extension> 
</xs:simpleContent> 
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</xs:complexType> 
</xs:element> 
<xs:element name="controls" type="controls-type" 
minOccurs="0" maxOccurs="unbounded"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:attribute name="name" type-"mixer-name-type" 
use="required"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:complexType> 


<!-- MIXER NAME TYPE --> 


<xs:simpleType name="mixer-name-type"> 
<xs:restriction base="xs:string"> 
<xs:pattern value="VideoIn"/> 
<xs:pattern value="Video0ut"/> 
<xs:pattern value="Audio0ut"/> 
<xs:pattern value="AudioIn"/> 
<xs:pattern value=".+"/> 
</xs:restriction> 
</xs:simpleType> 


</xs:schema> 


2012 
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